>> I like it! Really good. Maybe just a darker shade of blue there, and change the word ‘giant’ to ‘huge’. Other than that, it’s great!
>Let's change this to:
>> I like it! Really good. Can you briefly work me through the design process behind it? I'm particularly interested in how you settled on the colours over there, and your ideas behind the word 'giant'.
Take note, all ye entrepreneurs! This advice is just as applicable for software engineers as for designers, extremely so. So many issues could be avoided with people I do contracts for if they just approached issues in this way.
Usually, it's "change this, do that". So I have to reply with "OK, well, we could do that but it'll take 20 days and cost $3000 dollars". The entrepreneur, displeased yet unwilling to pay that much or give up that much time: "hrmph. well...".
Automatically, something that could have been a collaborative process has been turned into a confrontation. If he/she had instead approached the problem in the way you recommended, I perhaps could have found out what was driving the desire for change, and recommended a cheaper/faster solution to the problem. Usually, I'll end up in that place eventually, but by that time what could have been a collaborative process has turned confrontational, with my client thinking "ugh, programmers" and me thinking "ugh, idea guys".
That said, this has given me some ideas about how to respond in this types of situations. Perhaps with something like, "can I walk you through the reasons why I did/chose this?". Might be worth trying.
> You are not presenting a quantitative basis for a change. That "work me out of a design" is as diminishing as direct request.
First, you are still thinking in terms of a top-down decision where the boss has to choose between deciding what is best, or delegating that with no further input, whereas I'm talking about creating a collaborative dialogue which may or may not result in change at all.
> Please, answer to me why are you concerned with such minutiae next to project completion? Is the Statement of Work you have prepared with designer not detailed enough?
I'm describing a generalised approach based on the examples in the article. If you think this is a literal example of what to focus on, then I might as well throw back at you that what you are describing with SOWs sounds a lot like the fixed, rigid waterfall approach where everything is set in stone at the start, which in the words of Winston Royce himself "is doomed to fail".[0]
Which brings me to my second point: for the sake of the example I'm assuming here that this is not a bike-shedding situation where a manager just wants to change something for the sake of feeling like they added something to the conversation (in which case your only hope is to add something so trivial that it functions as a lightning rod - see the Duck story of Battle Chess[1]).
Let's assume that the boss in this scenario has a reason to want to change something better than bike-shedding. Whether it's a good or bad one is to be determined. Instead of assuming either, the best option then is to engage in a (brief) dialogue to figure out said reason. The designer, being the expert, should be the best person to guide the boss and help decide the validity of said input.
So the goal of this conversation is not to propose a change to "blue and huge". The goal is to approach the design from the point of view of the designer; focussing on the points that still somehow feel uneasy is just efficient since that is most relevant. By asking the designer to work us through the design process we get to ignore the first gut-feeling "solutions", letting the designer keep ownership and acknowledging that they know what they are doing.
If you approach the conversation like this, most of the time it will quickly become obvious that that one of the parties forgot to take something into account: maybe the shade of blue would align more with company colours, despite not popping out as nicely; or maybe it's the opposite: the darker shade would look better, but the designer decided being consistent with the overall look of the company was more important. Furthermore, discussions like this are immensely helpful for making it clear to the designer what metters most to the client. In the end the designer can walk away with a better understanding of their client's wishes: "ok, I'll have to figure out a new balance between aligning with the the company colours while still having some pop in the overall look - and I have a bit more leeway than I originally thought."
> I've been a designer for 12 years or so... I would get frustrated designing logos for small businesses because (a) it was so time-consuming to create 30 mockups, (b) it would take weeks to do those small back-and-forths, and (c) the logo would end up being so simple that I felt like that entire process was a waste... As soon as I had the idea ... I started working on it.
I think this is my favorite part of the story. If you've been a designer (or any profession) for over a decade, even with frequent frustrations, it takes a certain kind of humility and introspection to realize that maybe it's not just about your customers being "broken" (by choosing the designs that take the least effort) or needing to find more sophisticated customers who value your talents.
Sometimes (ok, usually) it makes more sense to build what people really want rather than giving them what we think they should want. As a developer and entrepreneur, I have to be reminded of that fairly often.
> Build around people problems, not company problems
This is so hard to fight for. I worked on a feature for our product where we leverage a UI component initially built to show ML recommendations, but to surface hard coded recommendations made by our partner's software, not coming from AI but hard coded. These recommendations are contextually sound because the devs _know_ what is possible given the context, which for all intents and purposes makes them much, much more relevant than anything that would come from an ML model. But for the life of them the other team will not let us use this UI because they're afraid that it might tarnish the opinion people have of their AI. So we're in this situation where the user would greatly benefit from a consistent UI, the partners as well, but because that team is afraid it will dilute their baby, we can't do it.
Had similar examples where 3 months in designinga feature it becomes clear that it doesn't fit with users, that a simpler solution would be better, but designers and PMs will take a hard stance that it's how we planned it and now is too late to change it even if dev hasn't even started.
Between sunk cost and babies, it's hard to forget our own interest in favor of our users.
> Forcing people to “actively read, think, and respond” is a great way to increase the likelihood that the best ideas bubble up to the top.
I think that it requires acknowledgment that there are two sides to such issues; as someone who is on the side that typically ends up having to handle the majority of the busy work to get many proposal through in my company I absolutely want the proposer to make the effort to figure out the stakeholders/costs/challenges for their project as well as answers. I'm willing to __fill in gaps__, but I don't really want to be having to do the basic legwork for someone else's project.
I don't mean to sound like I want to stifle inconvenient creativity; it's certainly not the case, and when someone has really taken the time to make some new tooling/project with benefits and acknowledges the costs involved, I'm more than happy to champion such projects.
But when someone just has a desire (or disparagingly, a whim) to change stuff up because it simplifies their workflow and they expect someone else to handle all of the communication of their project without even giving me the courtesy of doing such research, I cannot deny I approach such proposals negatively as I feel a bit used and I think that the expectation is "I want this, make it happen", which is not my job.
Similarly, I find myself encountering persons who expect that I and the rest of the company will magically intuit the importance of very niche projects without being willing to take the time to simply explain the pain point they wish to address. I'm not even talking about deep technical details here, but simple things like:
"We spend N amount of time on task X"
"I have an automation workflow that will require Y hours to implement, but N is reduced by Z [time value]"
Instead, the presentation is "I want to implement this automation workflow; what do you mean explain the value? Can't you see it? Why are we so caught up in corporate bureaucracy?"
I'm all for reducing N as much as possible, but if I myself can't explain why spending Y is vastly cheaper than N, I have no confidence in my ability to convince others that the cost of Y is worth it.
I've truly been on both sides, and it is some work to justify a change, sure. Formal proposal documents are a bit much for my taste, but whether we like it or not, C-Levels aren't going to read your code and they definitely aren't going to read a 2000+ word stream-of-consciousness email describing the project in an unstructured way (much less any git readme.md files). The impetus is on the person proposing the change to at least make an effort to convey the reason for the change to the relevant stakeholders.
> The problem is that if a company uses its name and charges the same amount as it’s other services there is an inbuilt level of expectation which leads to disappointment.
> Personally I can’t think of a single application that couldn’t be better in some way.
> The solution to this would be to temper peoples expectations and host these types of projects under a different domain that clearly explains that the project is very early in production. Providing an opportunity to give feedback would also make people feel more involved in the projects and give projects that have no clear vision some guidance.
> The problem is that if a company uses its name and charges the same amount as it’s other services there is an inbuilt level of expectation which leads to disappointment.
> Personally I can’t think of a single application that couldn’t be better in some way.
> The solution to this would be to temper peoples expectations and host these types of projects under a different domain that clearly explains that the project is very early in production. Providing an opportunity to give feedback would also make people feel more involved in the projects and give projects that have no clear vision some guidance.
>Forcing people to justify, out loud, why they want to use a specific technology or trendy design pattern is usually sufficient to scuttle complex plans.
Does that really work ?
Usually these guys read the sales pitch from some credible source. Then you need to show them that the argument is X works really well for scenario Y but your scenario Z is not really similar to Y so reasons why X is good for Y don't really apply. To do this you usually rely on experience so you need to expand even further.
And the other side is usually attached to their proposal and starts pushing back and because you're the guy arguing against something and need a deep discussion to prove your point chances are people give up and you end up looking hostile. Even if you win you don't really look good - you just shut someone down and spent a lot of time arguing, unless the rest of the team was already against the idea you'll just look bad.
I just don't bother - if I'm in a situation where someone gives these kind of people decision power they deserve what they get - I get paid either way. And if I have the decision making power I just shut it down without much discussion - I just invoke some version of 'I know this approach works and that's good enough for me'.
> This happens all the time in orgs all over the planet.
> You are truly insufferable and making incorrect assumptions. This happened once, in my current role.
> Now, please... do us both a favor and stop talking out of your ass.
I'm going to be blunt here. If it's anything like this to work with you (which I don't know, only your colleagues can say), then I think you have a lot to work on:
- You freely admit that you don't have a track record of working at orgs that insist on the highest standards for design
- You seem to harbor unchecked presumptions and lack the curiosity to seek them out
- You lash out at others who suggest that maybe these things are not universal
- You take little responsibility or ownership for the situation you're in
If I was a hiring manager for a team that cared about good design of any kind, why would I hire you? It would be like oil and water. It's one thing to end up in an org practicing your craft in a way where quality just isn't appreciated. And I imagine many of us have been there (I certainly have). But, it is another thing entirely to extrapolate it to a universal circumstance, or into something unavoidable.
Figuring out how to adequately communicate and tradeoff the short term and long term value of good design to other stakeholders in the company is one of the /bare minimums/ to being a competent designer. Why would I trust you to visually communicate something to a customer if I cannot even trust you to verbally communicate properly with your team? I have very rarely worked with designers unable to do that with a variety of stakeholders. And honestly, if you cannot do that successfully, I think you need to go back and work on your fundamentals.
> It makes these arguments a lot easier to win if you have a mature design practice with good leadership who can say “What biz/sales/product are asking for is not feasible as it violates our established criteria for dark patterns”.
We don't really have established criteria, we're a smaller org and typically it's been the developers that have resisted implementing any dark patterns while offering alternatives and product has historically been supportive of this.
And yeah since we're a small org, we have a small design team with just a few floating designers. The example I mentioned was with just one in particular and the only one my team really works with.
> One would assume so. That's not always the case in my experience. Improvisational discussion of design tradeoffs and costs happen a lot. YMMV, I guess.
They certainly do, but significant, unchangeable decisions should not be made that way. If I think there is a better alternative to something expressed in one of these discussions, but do not have the details at hand to make the case, I will voice the alternative and compile the details later. Choices like that should not be made without documented rationale anyway.
> I'd agree with that, but design processes on the whole tend to more dysfunctional than organizations realize. There's still a lot stuff running on deprecated OSs, dead languages, and mountains of technical debt.
The solution is to fix the organizational dysfunction. Hiring to the dysfunction is a band-aid at best.
> If it works, but it offends your sensibilities, perhaps this is an opportunity for self-growth.
I've had to learn this lesson. We have an internal microservice whose name is obsolete and no longer makes any sense whatsoever. Everyone is confused by the name until the original reasoning is explained, and they come to understand the original purpose of the service, now long since changed. It drives me up the wall.
I have time and time again made a case for renaming it to accurately represent its modern purpose, which would take an engineer about a week of work - there's a lot of code and config that has to be switched over.
The person running my division has shut me down on this over and over. It goes like this:
Manager: Why do you feel this is a priority?
Me: It confuses people and makes the code less self-explanatory.
Manager: How much time is this costing engineers?
Me: Well, about a minute every time I have to explain it to someone once a week.
Manager: And it would take a week to update? This doesn't seem like a good trade.
Me, mentally spluttering: But the name makes no sense!! It's the wrong name!! It's completely unrelated and has no meaning!
Manager: Do you think you can work with it anyway?
Me: sadly sighs.
I think the manager is right, as much as it offends my sensibilities.
> They often don't really understand my use case. They only hear one part of what my team is trying to do, and then act like they know what I need. Yes, your suggestion works for the use case you know about, but not for the 10 other use cases I need to design for.
So then can you not say "but I also have REQUIREMENT_X for this project? Do you think that your solution will mesh with this other need I have?"
If you can't have a technical discussion defending why you feel your solution is the best then you must not be confident about your solution.
>Why do people want everything for free when other have put a lot of effort on making it?
I don't think that's the problem. People will pay if what you build solves their problem. More specifically, they'll pay if they see that what you build solves their problem.
Before building, you should check:
1. Do they have a problem?
2. Do they know they have a problem?
3. How much of a problem is it for them?
4. Who, exactly, has the ability to act on this problem?
5. What language do they use to describe the problem?
6. Do they have any requirements that aren't obvious to me? Can I incorporate them into what I'm building?
If this sounds like marketing, it is, but it's the good sort. Building something people don't actually want is a perennial problem.
Rather than trying to sell what you have, figure out what they want. Then you'll know whether to:
> Don't hire people for stupid things. Adobe cloud is 20 bucks a month, read a few books, watch a few videos and make simple designs yourself. If your thing takes off, you can always hire for better later.
This resonates so much. My company hires and outsources for the most stupid things, like, we need to change colors on a design file or move some buttons around? Let's go on Upwork or through our address book, write a RFQ, have a meeting to evaluate the quotes, set up payment and contract, then in two or three weeks the "refresh" is done.
I mean, just open Figma or whatever tool and do it yourself. Or ask a colleague for 20 minutes of help. It doesn't take Van Gogh to pair two colours and fonts.
> I have the benefit of time to develop an argument and resources with which to do so.
One would assume so. That's not always the case in my experience. Improvisational discussion of design tradeoffs and costs happen a lot. YMMV, I guess.
Though I agree that no-google, closed-book, no-IDE whiteboard development is very unnatural.
> ...if your company makes significant decisions like that in a single 45-minute (or any length, really) meeting you need to change your design process, not your hiring process.
I'd agree with that, but design processes on the whole tend to more dysfunctional than organizations realize. There's still a lot stuff running on deprecated OSs, dead languages, and mountains of technical debt.
> he only wants to chain existing solutions, rather than trying to imagine how we can make things better.
You have to meet in the middle. Nobody wants to reinvent the wheel - it's not good faith to accuse someone of laziness for trying to suggest a realistic product roadmap. If you're more caught up on the current SOTA in your field and feel that there's a better solution, the onus is on you to write that code. Your employee could still be a 10x engineer if you delegate meaningful work to them, but right now it sounds like you do have unrealistic expectations for them.
You shouldn't expect to find anyone more passionate about your product than you are. I'm not sure if you can focus on "other projects" while paying someone to invent your Magnum Opus for you.
>When we started, we figured that customizing business software by ourselves was something we'd never be able to scale properly
This is the meaning of the badly put advice "do things that don't scale".
Regarding your vision of offloading the work to partners, my experience is that more time can be put trying to convince prospective partners than doing the work yourself if you are not careful.
My feeling is that you are anticipating hyper growth a bit too much. Start by doing all this work yourself, and you'll have no problem to scale with the income you'll earn.
This is assuming you price your product appropriately so that you are profitable on every transaction and customer.
> Or maybe there are bigger fish to fry and it’s not worth quibbling over small things.
I've taken this approach with one of our engineers, and now we have a huge pile of "small things" that has created some pretty serious technical debt.
My perception is that they don't try to understand what I'm pointing out, and come up with rational for how they have it. I think I have a lot to learn.
Take note, all ye entrepreneurs! This advice is just as applicable for software engineers as for designers, extremely so. So many issues could be avoided with people I do contracts for if they just approached issues in this way.
Usually, it's "change this, do that". So I have to reply with "OK, well, we could do that but it'll take 20 days and cost $3000 dollars". The entrepreneur, displeased yet unwilling to pay that much or give up that much time: "hrmph. well...".
Automatically, something that could have been a collaborative process has been turned into a confrontation. If he/she had instead approached the problem in the way you recommended, I perhaps could have found out what was driving the desire for change, and recommended a cheaper/faster solution to the problem. Usually, I'll end up in that place eventually, but by that time what could have been a collaborative process has turned confrontational, with my client thinking "ugh, programmers" and me thinking "ugh, idea guys".
That said, this has given me some ideas about how to respond in this types of situations. Perhaps with something like, "can I walk you through the reasons why I did/chose this?". Might be worth trying.
reply