>It should be noted that some young designers have been known to exhibit behaviors of senior designers. And on rare occasions, you may see a senior designer in the wild behaving like a young designer. Scientists cannot confirm why this phenomenon exists.
It's called personality. Not everything needs 20 years of adulthood to be cultivated, some are born with it or grow into it young. About time the industry starts putting their money where their mouth is and take that 'people are different' advice themselves.
I still usually ask what the deadline is. The reason is given in the same article: "as many drafts and explorations as possible within the time allotted, then shares their favorite options."
The words "junior" and "senior" literally mean "younger" and "older". If you're not happy with age being a proxy for experience, then you shouldn't be happy with these words either.
That might be true if you learned English from reading a dictionary, but for the rest of us we have a thing called 'context', and we understand that meanings vary depending on it. A title of "junior designer" obviously doesn't mean "young designer" to anyone who's ever read a job description before.
The article left a bitter taste. It's probably intentionally all black and white, but it does sound almost passive-aggressive to me.
I can safely consider myself senior designer (doing UX design for more than 20 years).
I always ask about deadlines. I believe not doing so is highly unprofessional. I have other tasks in parallel, clients have other tasks in parallel. Deadlines = priorities. Discussing priorities is critical.
I only "explore beyond just one idea" if agreed with the client.
Of course I explain what I did and why, but I also say “let me know what you think!”.
I never actually ask for help :-) But if I did, "asking for help by proposing a solution" seems counter-productive to me.
I disciplined myself to never "struggle" while working. But this line - "One blames their manager, mentor or client for their struggles. The other keeps working." - just sounds wrong to me.
I also think the most important piece is left behind in the article. The secret of successful UX design is to understand deeply what problem(s) your design is solving. Then it's just a matter of finding the best solution to these clearly defined problems and "designing" it.
For me it also sounds passive aggressive in the sense "junior designer doesn't know anything, lacks things like common sense and even personality, this is why I pay them 5X less than myself". While me - a senior designer - explores beyond ideas ASAP while investing in researching clients industry to write own copies while choosing directions and overseeing execution while at the same time just doing the job required.
Some of these even contradict one another:
> The other knows the answer is "ASAP,” so they propose their own timeline.
> The other does as many drafts and explorations as possible within the time allotted, then shares their favorite options.
Sounds for me like some senior punishing juniors with "do it ASAP! you only did one draft? do more! ASAP!"
Maybe I am imagining things or maybe I met colleagues/clients like that.
> The other does as many drafts and explorations as possible within the time allotted, then shares their favorite options.
Yeah, not really. Given timeline and workload, I will probably polish a bit more and maybe let something sit for a few days before going back for another iteration if the schedule allows. But sometimes things really are done--or at least done enough for the purpose. I'm not going to just let the work expand to fill the time allotted if there's no real benefit to doing so.
Yeah, many of these are bullshit or only valid in very specific circumstances.
On deadlines: sometimes there is none. Of course it still needs to be done, but it needs to be done correctly, so you set your own timeline based on sustainability. Things can be high priority and still not have an actual deadline. But sometimes it really needs to be done in a week or a month because it's tied to a big promotional campaign or it needs to be presented to important stakeholders or whatever, and you need to drop everything to whip something up that does the job and tech debt be damned. But if the actual deadline is "yesterday", then it's already too late and doesn't have to be done anymore; that's not a deadline, that's fake urgency.
(I realise the article is about design, not programming, so maybe tech debt is not a concern there, but I'd expect there are other quality aspects that matter.)
These are completely different situations and need to be treated completely differently. Only an idiot would assume there's only one answer to the deadline question.
With any work ask about external factors, not deadlines. No company operates in vacuum and there’s almost always an external factor. It may be well-defined and clearly dated (a scheduled event or launch in which your work plays part). There could be an external factor not explicitly connected to your work, even though it should be (you could help make that connection). No external factor whatsoever concerning your work is also informative: it could mean there’s not enough mutual trust, or your customer is investing into pure R&D, or it’s very low-priority, there’s a disagreement within the company, etc. It’s not the same as asking about deadlines, but the question should definitely be asked (and situation monitored for changes)—proposing a schedule/“deadlines” without awareness about external factors sounds like a bad idea.
Some customers may be inclined to manage more and set specific deadlines rather than get into the external factors discussion. This spares you from some higher-level planning but doesn’t fundamentally change the ultimate responsibility of managing expectations (aiming to under-promise) regarding work scope and timeframe: fixed scope means variable timeframe, fixed timeframe only means you adjust the scope part of the equation. If expectations are unrealistic and there’s no flexibility in either direction, run.
Design can definitely generate technical debt. If the designer specifies that some widget has to look and behave just so, then some developer has to code a widget that meets that requirement.
IME a lot of design work is purely aesthetic, and a matter of taste. That is, it's not functional; you could have used a native browser widget instead, but designer says no. And in the last shop I worked in, the designer had the whip hand, partly because the boss couldn't code, and partly because designers cost more than grunt front-end developers.
So you end up with a pile of unnecessary front-end code that becomes a breeding ground for bugs and regressions. Not quite the definition of tech debt; but unnecessary code quickly turns into tech debt.
> I always ask about deadlines. I believe not doing so is highly unprofessional.
To be fair though, the article didn't say no deadlines; it said propose your timeline, meaning (if I understand it correctly) let the client know your availability as well as how long it normally takes you to do tasks like this. The client then will either accept your terms or look for another designer.
Perhaps I'm reading the post the wrong way, but particularly in the case of junior v. senior, I see the deadline point to be more about what a designer can do, given their experience and seniority. A junior designer is going to be handed an assignment and told "we need this next Friday." A senior designer will likely be handed an assignment (or work with a client directly) and be asked "when can we expect some initial ideas?" It's less about what a designer of a certain experience should do, but rather what they can do.
I'm an software engineer, not a designer, but I also was left with a bitter taste.
Re >> The other does as many drafts and explorations as possible within the time allotted, then shares their favorite options.
It's good to ideate, but I've found that it's common for junior designers to ideate too much. For example, I had a designer come back with some designs that they felt really excited about, but they all were tied into a new company logo concept and I was like "No, we're not changing our logo. Your logo looks great, and if you/this logo had been included when we first picked something we might have gone with it, but we're asking you to design these XYZ pages, not re-do our startup branding".
If the brief is vague enough to omit things like "don't rebrand everything" that falls mostly on the person leading that project, in my book, although a more seasoned designer might have challenged the scope definition more.
Yes, "senior designers are jaded" should be added to the list — probably a differentiator between "senior" and "principal" to get over that sort of passive-aggression.
I suspect this could apply to UI design (ok UX...) but I read it with product design / industrial design in mind. I worked on a project with a really good design team (2 or 3 people) and a bunch of engineers. We used a large conference room to go over the product objectives, and then we all paired up with designers to generate concept art. We all did this for like an hour or two. At the end they pinned up about 50 concept drawings at the front of the room and we talked about a lot of the ideas that had been generated. The thing turned out pretty spectacular. The lead designer moved on, last I knew he had gone to Rivian to work on their first truck under the direction of some famous design guy whose name escapes me just now.
I think the biggest difference is the senior ones know their product and can recognize edge cases or other implications of their designs. My biggest challenge working with ux designers is them creating UX flows or interfaces for one particular case and not thinking at all about how this is going to work when edge cases happen.
> "One asks when the deadline is. // The other knows the answer is "ASAP,” so they propose their own timeline."
There's nothing wrong asking what the deadline is. Most projects can be strategic, meaning that the force of will is focused on a bigger picture/opportunity than planning the design beforehand. Also, an experience designer WILL ask because he can propose a realistic outcome based on the deadline (ex. do you want this project before Feb? Then we must take out of the equation feature X, Y, Z) since the designer is able to measure the speed of production.
> "One designs exactly what they’re told. // The other knows what they’re told is just one idea, and explores beyond it."
This is the biased author thinking, again, doing what they've told is BAD, when it's not. If the company wants X, why would it be wrong to do that? They asking you, the pro, to deliver that, why on earth would be good to design a plane when you've told to do design a car? The argument is silly.
> "One turns in their first or second draft. // The other does as many drafts and explorations as possible within the time allotted, then shares their favorite options."
Doesn't sounds professional to design 30 logos and share my 10 favourite logos" agains junior studied and poured everysingle thought on one design.
I don't think the author of the article really seat down and think every single argument.
The second point is that most people don't know what they want until you show it to them. Designing what you're told only works with people who have done the exploration themselves, which tends to be a tiny minority (because it essentially requires the design skills that they're expecting from the designer themselves).
Well, one of the traits of a designer is being able to master draft anything in couple of hours, max. Also, PMs should help on teorizing what would a product be like. That helps to create expectations, but also, helps the designer to see what's the idea they want. The designer in the end will make all the needed changes in order to deliver a performant design.
You're coming at it from a different context than the original article, which is more about what an agency would do, where there won't be PMs and designers have to figure out requirements themselves (often precisely by challenging what the client is asking for).
Is this supposed to be tongue-in-cheek?
Because if this is serious than I hope I will never have to work with this guy.
It screams bro/hustle-culture with a side of vain elitism.
All of it reads so... arrogant?
It's also just wrong. I'm no senior designer, but all of his points advocate for less communication and projecting absolute confidence in situations where it's not at all warranted. Preventing misunderstandings is only possible with more communication, not less. Instead of working with you this guy will just straight up choose what to do and if you disagree then you're wrong.
I've worked with designers like this. They don't understand the product as much as they think and generally don't get the technical landscape they're dealing with. I've had to push back (successfully) and have product+design come to the team with more of a problem statement and less of a shiny Figma. The projects with problem statements tend to have less "Jira churn" where we have minor bug reports for styling or UX at the end of a project.
Before switching to web dev, I was a pretty seasoned graphic designer.
> One asks when the deadline is.
> The other knows the answer is "ASAP,” so they propose their own timeline.
How on earth are you prioritising your work? Or are you in some mythical design job where you only have one thing on the go at once?
> One designs exactly what they’re told.
> The other knows what they’re told is just one idea, and explores beyond it.
It depends on the client. There are many clients out there who have a vision, and only want that vision. Is it really worth your time to argue your case with them? A real senior knows that the best way forward in those cases is to do what they want, get paid, and hopefully get a more interesting job next time.
>One turns in their first or second draft.
>The other does as many drafts and explorations as possible within the time allotted, then shares their favorite options.
Depends on deadlines. Some projects only have enough time for a couple of variations. Some clients don't want to pay for hours of iterations. In university you have the luxury of spending literally months on individual projects, making hundreds of iterations. It's really rare to have that in the real world. Those jobs are out there, but they're very very uncommon.
>One uses Lorem Ipsum.
>The other writes their own copy to the best of their knowledge and ability.
This is bullshit. The designer should not be a copywriter in practically any case. If you're doing typographical artwork, then sure, every letter matters. If you're just laying out an editorial piece, lorem ipsum is more than fine for getting the general characteristics of the layout down until you can drop in the real copy and refine.
> One sends their design saying “let me know what you think.”
> The other explains what we’re looking at and why they made the decisions they did.
Sort of valid. Hopefully shouldn't have to explain yourself in words too much since we're supposed to be communicating visually here (our clients' customers aren't going to be getting our explanations), but asking for open-ended feedback isn't very useful.
> One asks for help.
> The other asks for help by proposing a solution.
This is just about asking for help only after trying to figure it out yourself. Most juniors do this already.
> One completes a task and moves on to the next one.
> The other completes a task and sees it through to execution.
Anything like this should be agreed before work starts. If it's designed before work starts, then it is part of the task by definition. If anything crops up during the project that could be improved, or you feel has been missed, then obviously bring that up to the client and potentially expand the scope of the task. Not really seeing a junior-senior divide here.
> One waits for directions.
> The other chooses a direction based on the information they’ve already been given.
As always, it depends. Is the information you've got enough to make an actual start? Or is it very likely that you'll waste hours of the client's time and have to scrap your work once more information comes to you? Running headfirst into a project before you have what you need is a recipe for time-wasting.
> One blames their manager, mentor or client for their struggles.
> The other keeps working.
This just sounds like the author is trying to put-down people struggling in companies that offer them poor support. There is nothing wrong with complaining about poor support structures at work. Acting like you're superior for just taking it is, frankly, odd.
You’re prioritizing your work through the timeline you proposed, rather than asking someone else to prioritize your work for you. Yes, the person you made the proposal to may push back but the senior person starts the discussion.
While I don't agree with every little thing in the article, you took the key points and put your own explanations of them; yet you have ignored the elaborations the author provided where they touch your points too.
I'm sure these are things designers will learn. I'm not sure that they really separate a junior from a senior designer though.
At least in product design when you hire a senior designer, you're hiring a set of beliefs about how software is designed and built. They should have pretty well-founded opinions on a variety of things. I wouldn't expect a junior designer to have formed those yet.
For me, this article comes around more as a designer-influencer production than a form of deep insight.
He writes polarizing content and converts the reaction to "his own service for designers portfolios". Regularly.
>One asks when the deadline is.
The other knows the answer is "ASAP,” so they propose their own timeline.
I always ask when the deadline is. Design is part of the production process. The production process even when I control it (as a PM and PD) is bound to the projected timeline.
>One designs exactly what they’re told.
The other knows what they’re told is just one idea, and explores beyond it.
Again, there is a place and time when you design to spec and exploration is not limitless. Exploration has boundaries.
>One turns in their first or second draft.
The other does as many drafts and explorations as possible within the time allotted, then shares their favorite options.
Actually in high level design thinking, designers "favorite" option has no merit.
Forming a logical design solution over a set of UX research data and actual testing is the winning method.
There was a book I read one time, early in my journey, called "Hardcore Java" It's promise was to take you from beginner java engineer to an advanced one. It was written by someone who "knew" the craft and was ready to pass on their anointed knowledge.
The author of the book had just recently made the progression to what they considered advanced, so the book was chock full of beginner-cum-expert advice like this article.
And it was all wrong. The errata for the book is more pages than the book itself. It had the basics of java incredibly wrong, most of the code samples in the book were not compilable, it was a mess.
This article strikes me the same way. Someone who has a little more knowledge than a beginner, but hasn't yet learned how little they know. So they want to show off their new knowledge with gatekeeping "lessons"
The difference between junior and senior isn't just about going from "easy way" -> "best way" It's about understanding when you can get away with the easy way, when the best way is too hard for a situation, or the situation isn't called for. It doesn't fit nicely into X does Y and A does B. Design/Engineering isn't black and white.
About the only point I agree with is the "Lorem Ipsum" point.
To put it in another way, try to design with realistic data. Eg designing a grid layout with lorem ipsum filler content can easily lead to not addressing issues when presented with real data. What do you do when a title wraps to the next line? How do you handle different length descriptions. Is some of the data optional?
> To put it in another way, try to design with realistic data.
Also known as "the design won't work in German". Seriously though this drives me nuts when I get a design with perfectly lined up, even amounts of text.
Oh, that's the one that bothered me most. If you can guess how long the copy in each section is in order to write it, you can just fill in that same space with lorem ipsum, and now you haven't wasted time working on something that's going to be thrown away.
Testing with multiple lines and strings of different length is a different matter — you should do that anyway. But writing paragraphs of marketing copy and headlines? Not a good use of my time.
I'd just be happy if I came across more "senior" "web" designers that actually understand UX. All of the ones I've come across wouldn't know how a checkout workflow works in practice and will happily remove necessary fields, information, or steps because it doesn't look pretty.
Like... we do need a way where the user can see a summary of their purchases (and adjust quantities) before paying for them. Also, limiting quantity to 9 because 10 is too wide is just... I have no words.
>> I'd just be happy if I came across more "senior" "web" designers that actually understand UX.
Not sure if you were around the web in the 1990's. HTML was really cool, you just wrote it and the browser reflowed everything to the users screen. Then the web went commercial and a bunch of people from the print industry came along and wanted to specify the exact page layout of everything. Things changed rapidly. I mean now they even want to not only specify fonts, but have custom ones made. Ugh.
I actually liked the list. I see past the literal meaning of each sentence into situations I've seen managing designers in the past.
On deadlines: Sometimes there is pressure from the top that is completely unrealistic. I think it is ok to ask for a deadline, but I think it's better to propose a timeline as a way of getting to the stakeholder's real deadline in a manner that gets them amenable to reduce scope. It's an exercise in educating the stakeholder about the sheer weight of the ask. Time, money, output. Pick the one you care about the least.
On multiple designs: Of course for this one it depends. A simple button or form on a secondary page does not need several rounds of polish and iteration. Star feature on an upcoming flagship product, though, does.
On explaining decisions: This is mostly about getting buy-in from multiple stakeholders. I may be CTO and love the new design, but there are three other chairs in the room looking at the work and its more efficient if you prime the meeting with the constraints you were dealing with. A strong secondary benefit is that it makes you easier to recommend to others, since a big part of a strong referral is trusting that the referred party can properly portray themselves and their work to others.
On waiting for directions: If you've never managed juniors this may come as a shock, but a large number of juniors will sit and wait until they're told what to do. It is partially explained by cultural background at times, but its present everywhere I've worked. If one thing juniors took away from the article was this, then I would count that as a major win.
I could go on, but my overall point here is that many commenters are looking at this as designers that are focussed on specific skills of the craft, instead of seeing it as a stakeholders point-of-view on junior versus senior designers.
There is one thing I would add to the list that transcends the junior-senior distinction: Nothing beats an honest, enthusiastic designer.
I wonder about this stakeholders pov idea. One thing I've seen at big companies are situations where "junior" folks are tasked with a laundry list of bullet points and that's all that they're given.
So then the senior folks are free to do much of what is in that article... because that's their job.
It's not a senior person chooses to do these things and jr do not. It's straight up the roles they're given.
That's not a situation where someone's skills / enthusiasm / intuition means they do these things, they're just afforded / expected to.
I am not a designer, however in my line as a software engineer I have learned that sometimes it’s better to ask for feedback without immediately giving a potential solution.
Doing so can seriously limit the creative freedom of the other person by shoehorning them into a specific line of thinking. Sometimes the best feedback you can get is reconsideration from a completely different angle.
This obviously doesn’t apply to everything, especially not if the answer is quickly googled. But complex or project specific decisions can benefit from multiple people coming to their own conclusions. Especially so if the individual ideas are then the same or at least partially overlap.
53 comments
[ 68.2 ms ] story [ 2688 ms ] threadIt's called personality. Not everything needs 20 years of adulthood to be cultivated, some are born with it or grow into it young. About time the industry starts putting their money where their mouth is and take that 'people are different' advice themselves.
I can safely consider myself senior designer (doing UX design for more than 20 years).
I always ask about deadlines. I believe not doing so is highly unprofessional. I have other tasks in parallel, clients have other tasks in parallel. Deadlines = priorities. Discussing priorities is critical.
I only "explore beyond just one idea" if agreed with the client.
Of course I explain what I did and why, but I also say “let me know what you think!”.
I never actually ask for help :-) But if I did, "asking for help by proposing a solution" seems counter-productive to me.
I disciplined myself to never "struggle" while working. But this line - "One blames their manager, mentor or client for their struggles. The other keeps working." - just sounds wrong to me.
I also think the most important piece is left behind in the article. The secret of successful UX design is to understand deeply what problem(s) your design is solving. Then it's just a matter of finding the best solution to these clearly defined problems and "designing" it.
Some of these even contradict one another:
> The other knows the answer is "ASAP,” so they propose their own timeline.
> The other does as many drafts and explorations as possible within the time allotted, then shares their favorite options.
Sounds for me like some senior punishing juniors with "do it ASAP! you only did one draft? do more! ASAP!"
Maybe I am imagining things or maybe I met colleagues/clients like that.
Yeah, not really. Given timeline and workload, I will probably polish a bit more and maybe let something sit for a few days before going back for another iteration if the schedule allows. But sometimes things really are done--or at least done enough for the purpose. I'm not going to just let the work expand to fill the time allotted if there's no real benefit to doing so.
On deadlines: sometimes there is none. Of course it still needs to be done, but it needs to be done correctly, so you set your own timeline based on sustainability. Things can be high priority and still not have an actual deadline. But sometimes it really needs to be done in a week or a month because it's tied to a big promotional campaign or it needs to be presented to important stakeholders or whatever, and you need to drop everything to whip something up that does the job and tech debt be damned. But if the actual deadline is "yesterday", then it's already too late and doesn't have to be done anymore; that's not a deadline, that's fake urgency.
(I realise the article is about design, not programming, so maybe tech debt is not a concern there, but I'd expect there are other quality aspects that matter.)
These are completely different situations and need to be treated completely differently. Only an idiot would assume there's only one answer to the deadline question.
Some customers may be inclined to manage more and set specific deadlines rather than get into the external factors discussion. This spares you from some higher-level planning but doesn’t fundamentally change the ultimate responsibility of managing expectations (aiming to under-promise) regarding work scope and timeframe: fixed scope means variable timeframe, fixed timeframe only means you adjust the scope part of the equation. If expectations are unrealistic and there’s no flexibility in either direction, run.
Design can definitely generate technical debt. If the designer specifies that some widget has to look and behave just so, then some developer has to code a widget that meets that requirement.
IME a lot of design work is purely aesthetic, and a matter of taste. That is, it's not functional; you could have used a native browser widget instead, but designer says no. And in the last shop I worked in, the designer had the whip hand, partly because the boss couldn't code, and partly because designers cost more than grunt front-end developers.
So you end up with a pile of unnecessary front-end code that becomes a breeding ground for bugs and regressions. Not quite the definition of tech debt; but unnecessary code quickly turns into tech debt.
To be fair though, the article didn't say no deadlines; it said propose your timeline, meaning (if I understand it correctly) let the client know your availability as well as how long it normally takes you to do tasks like this. The client then will either accept your terms or look for another designer.
Re >> The other does as many drafts and explorations as possible within the time allotted, then shares their favorite options.
It's good to ideate, but I've found that it's common for junior designers to ideate too much. For example, I had a designer come back with some designs that they felt really excited about, but they all were tied into a new company logo concept and I was like "No, we're not changing our logo. Your logo looks great, and if you/this logo had been included when we first picked something we might have gone with it, but we're asking you to design these XYZ pages, not re-do our startup branding".
> "One asks when the deadline is. // The other knows the answer is "ASAP,” so they propose their own timeline."
There's nothing wrong asking what the deadline is. Most projects can be strategic, meaning that the force of will is focused on a bigger picture/opportunity than planning the design beforehand. Also, an experience designer WILL ask because he can propose a realistic outcome based on the deadline (ex. do you want this project before Feb? Then we must take out of the equation feature X, Y, Z) since the designer is able to measure the speed of production.
> "One designs exactly what they’re told. // The other knows what they’re told is just one idea, and explores beyond it."
This is the biased author thinking, again, doing what they've told is BAD, when it's not. If the company wants X, why would it be wrong to do that? They asking you, the pro, to deliver that, why on earth would be good to design a plane when you've told to do design a car? The argument is silly.
> "One turns in their first or second draft. // The other does as many drafts and explorations as possible within the time allotted, then shares their favorite options."
Doesn't sounds professional to design 30 logos and share my 10 favourite logos" agains junior studied and poured everysingle thought on one design.
I don't think the author of the article really seat down and think every single argument.
I told them I would update it in a week. I didn't get to it. I go to the next meeting and before I can apologize for not making the changes.
"We love the changes! Keep it like it is now!"
I think they just needed to see it twice...
All of it reads so... arrogant? It's also just wrong. I'm no senior designer, but all of his points advocate for less communication and projecting absolute confidence in situations where it's not at all warranted. Preventing misunderstandings is only possible with more communication, not less. Instead of working with you this guy will just straight up choose what to do and if you disagree then you're wrong.
> One asks when the deadline is.
> The other knows the answer is "ASAP,” so they propose their own timeline.
How on earth are you prioritising your work? Or are you in some mythical design job where you only have one thing on the go at once?
> One designs exactly what they’re told.
> The other knows what they’re told is just one idea, and explores beyond it.
It depends on the client. There are many clients out there who have a vision, and only want that vision. Is it really worth your time to argue your case with them? A real senior knows that the best way forward in those cases is to do what they want, get paid, and hopefully get a more interesting job next time.
>One turns in their first or second draft.
>The other does as many drafts and explorations as possible within the time allotted, then shares their favorite options.
Depends on deadlines. Some projects only have enough time for a couple of variations. Some clients don't want to pay for hours of iterations. In university you have the luxury of spending literally months on individual projects, making hundreds of iterations. It's really rare to have that in the real world. Those jobs are out there, but they're very very uncommon.
>One uses Lorem Ipsum.
>The other writes their own copy to the best of their knowledge and ability.
This is bullshit. The designer should not be a copywriter in practically any case. If you're doing typographical artwork, then sure, every letter matters. If you're just laying out an editorial piece, lorem ipsum is more than fine for getting the general characteristics of the layout down until you can drop in the real copy and refine.
> One sends their design saying “let me know what you think.”
> The other explains what we’re looking at and why they made the decisions they did.
Sort of valid. Hopefully shouldn't have to explain yourself in words too much since we're supposed to be communicating visually here (our clients' customers aren't going to be getting our explanations), but asking for open-ended feedback isn't very useful.
> One asks for help.
> The other asks for help by proposing a solution.
This is just about asking for help only after trying to figure it out yourself. Most juniors do this already.
> One completes a task and moves on to the next one.
> The other completes a task and sees it through to execution.
Anything like this should be agreed before work starts. If it's designed before work starts, then it is part of the task by definition. If anything crops up during the project that could be improved, or you feel has been missed, then obviously bring that up to the client and potentially expand the scope of the task. Not really seeing a junior-senior divide here.
> One waits for directions.
> The other chooses a direction based on the information they’ve already been given.
As always, it depends. Is the information you've got enough to make an actual start? Or is it very likely that you'll waste hours of the client's time and have to scrap your work once more information comes to you? Running headfirst into a project before you have what you need is a recipe for time-wasting.
> One blames their manager, mentor or client for their struggles.
> The other keeps working.
This just sounds like the author is trying to put-down people struggling in companies that offer them poor support. There is nothing wrong with complaining about poor support structures at work. Acting like you're superior for just taking it is, frankly, odd.
Terrible article.
You’re prioritizing your work through the timeline you proposed, rather than asking someone else to prioritize your work for you. Yes, the person you made the proposal to may push back but the senior person starts the discussion.
At least in product design when you hire a senior designer, you're hiring a set of beliefs about how software is designed and built. They should have pretty well-founded opinions on a variety of things. I wouldn't expect a junior designer to have formed those yet.
He writes polarizing content and converts the reaction to "his own service for designers portfolios". Regularly.
>One asks when the deadline is. The other knows the answer is "ASAP,” so they propose their own timeline.
I always ask when the deadline is. Design is part of the production process. The production process even when I control it (as a PM and PD) is bound to the projected timeline.
>One designs exactly what they’re told. The other knows what they’re told is just one idea, and explores beyond it.
Again, there is a place and time when you design to spec and exploration is not limitless. Exploration has boundaries.
>One turns in their first or second draft. The other does as many drafts and explorations as possible within the time allotted, then shares their favorite options.
Actually in high level design thinking, designers "favorite" option has no merit.
Forming a logical design solution over a set of UX research data and actual testing is the winning method.
The author of the book had just recently made the progression to what they considered advanced, so the book was chock full of beginner-cum-expert advice like this article.
And it was all wrong. The errata for the book is more pages than the book itself. It had the basics of java incredibly wrong, most of the code samples in the book were not compilable, it was a mess.
This article strikes me the same way. Someone who has a little more knowledge than a beginner, but hasn't yet learned how little they know. So they want to show off their new knowledge with gatekeeping "lessons"
The difference between junior and senior isn't just about going from "easy way" -> "best way" It's about understanding when you can get away with the easy way, when the best way is too hard for a situation, or the situation isn't called for. It doesn't fit nicely into X does Y and A does B. Design/Engineering isn't black and white.
To put it in another way, try to design with realistic data. Eg designing a grid layout with lorem ipsum filler content can easily lead to not addressing issues when presented with real data. What do you do when a title wraps to the next line? How do you handle different length descriptions. Is some of the data optional?
Also known as "the design won't work in German". Seriously though this drives me nuts when I get a design with perfectly lined up, even amounts of text.
Testing with multiple lines and strings of different length is a different matter — you should do that anyway. But writing paragraphs of marketing copy and headlines? Not a good use of my time.
Like... we do need a way where the user can see a summary of their purchases (and adjust quantities) before paying for them. Also, limiting quantity to 9 because 10 is too wide is just... I have no words.
Not sure if you were around the web in the 1990's. HTML was really cool, you just wrote it and the browser reflowed everything to the users screen. Then the web went commercial and a bunch of people from the print industry came along and wanted to specify the exact page layout of everything. Things changed rapidly. I mean now they even want to not only specify fonts, but have custom ones made. Ugh.
On deadlines: Sometimes there is pressure from the top that is completely unrealistic. I think it is ok to ask for a deadline, but I think it's better to propose a timeline as a way of getting to the stakeholder's real deadline in a manner that gets them amenable to reduce scope. It's an exercise in educating the stakeholder about the sheer weight of the ask. Time, money, output. Pick the one you care about the least.
On multiple designs: Of course for this one it depends. A simple button or form on a secondary page does not need several rounds of polish and iteration. Star feature on an upcoming flagship product, though, does.
On explaining decisions: This is mostly about getting buy-in from multiple stakeholders. I may be CTO and love the new design, but there are three other chairs in the room looking at the work and its more efficient if you prime the meeting with the constraints you were dealing with. A strong secondary benefit is that it makes you easier to recommend to others, since a big part of a strong referral is trusting that the referred party can properly portray themselves and their work to others.
On waiting for directions: If you've never managed juniors this may come as a shock, but a large number of juniors will sit and wait until they're told what to do. It is partially explained by cultural background at times, but its present everywhere I've worked. If one thing juniors took away from the article was this, then I would count that as a major win.
I could go on, but my overall point here is that many commenters are looking at this as designers that are focussed on specific skills of the craft, instead of seeing it as a stakeholders point-of-view on junior versus senior designers.
There is one thing I would add to the list that transcends the junior-senior distinction: Nothing beats an honest, enthusiastic designer.
So then the senior folks are free to do much of what is in that article... because that's their job.
It's not a senior person chooses to do these things and jr do not. It's straight up the roles they're given.
That's not a situation where someone's skills / enthusiasm / intuition means they do these things, they're just afforded / expected to.
The other asks for help by proposing a solution.“
I am not a designer, however in my line as a software engineer I have learned that sometimes it’s better to ask for feedback without immediately giving a potential solution.
Doing so can seriously limit the creative freedom of the other person by shoehorning them into a specific line of thinking. Sometimes the best feedback you can get is reconsideration from a completely different angle.
This obviously doesn’t apply to everything, especially not if the answer is quickly googled. But complex or project specific decisions can benefit from multiple people coming to their own conclusions. Especially so if the individual ideas are then the same or at least partially overlap.
A senior designer know's deisgns should be accessible to people who don't use a mouse.