In my approach to working with clients, I usually get them on a call or in a meeting room to discuss their current problems that I’d get hired to solve. During this conversation we’d touch on various aspects, their requirements, metrics, ROI, etc, and I will keep noting stuff down to distill it into a brief statement, that looks like this:

From what you told me, it looks like you need to improve your internal communication and processes because they currently are in disarray and many people make mistakes which results in poor customer satisfaction ratings and reviews.

This becomes a brief and from there we move on to pricing and agreeing on doing a discovery/diagnostic sessions to uncover the way to achieve what they need.

During discovery we’ll usually come up with specifics and exact requirement, metrics and goals that will guide the rest, but the brief is usually very... brief.

The message on that mock-up was just for fun, though I understand where you're coming from.

Indeed, having equal weight for both of these actions could seem like giving users the ultimate power in a decision-making process, though in reality these messages are usually prompted by a specific action on user's behalf, making choice facilitation somewhat problematic with both actions looking the same. Context is the key to making sure the right options are presented at the right time.

An example could be a "Remove" action taken against several selected photos in an album. We could facilitate this action without requiring a confirmation at all (and deleting the photos immediately), or allow the user to confirm her action, because she may have tapped the "delete" button by accident (happens to all of us).

In the above scenario we could use "Cancel" and "Remove" actions. I would emphasise the "Cancel" button as the most prominent action, and here's why.

• Firstly, defaulting to a non-destructive action reduces the risk of data loss (it's in the user's best interest if they accidentally tapped on "Remove").
• Secondly, contrast is what helps people act quickly on cues, and they will complete a desired action quicker, whether it's "Remove" or "Cancel", when they can see the difference between actions at a glance.

Nudging can be used for either purpose, good or bad, and it's up to us as designers to decide what is in the user's best interest. We're only facilitating choice, and we can either do it in their best interest (user-centric), in our client's best interest (business-centric), or find a good balance between the two (which is usually what we're expected to do).

"I can't think of a scenario where the consequences of making a choice would be 'dire'."

As for the above, it's all personal what each of us considers to be 'dire'. For my girlfriend deleting a few photos she accidentally selected, because the actions weren't highlighted properly would be dire if she wouldn't be able to revert this, while I would not mourn a few lousy shots if I did it myself.

I don't think vision deficiencies were taken into account in this example. Accessibility isn't just about screeen readers but about making the content accessible to everyone.

The problem I see with the card links in your exmaple is that there is no clear signifier even for people with 20/20 eyesight and no vision deficiencies. To me they just look like a different way to present static content (with a mild exception for A, because it has an arrow pointing to the right, which might signify a link).

In addition, reliance on :hover and :focus states is a one-way street, as not all people will use them, especially on touchscreens. Adding a bit of colour to the link might a be a good first step to signify a link on a base level, then go a step further and add something like an arrow to the anchor text itsels that will signify going to another page (→, etc).

Also, if you rely on box-shadow alone, make sure to add an outline of some sort to the :focus state.

These aren't rules, but just guidelines from a few years of testing different content types and presentation for links with users, where accessibility was paramount to the end-experience. WCAG AA won't tell you everything, but it's a great start.

If anyone’s interested, here’s a post on why I decided to build Blindfold: https://matthewmorek.com/releasing-blindfold/.

responding to RFPs is a 100% required business skill

It depends on how you decide to run your business. I decided that RFPs are nothing but client wishlists in pursuit of a vendor, not a thinker, to do the job at implementing it, and I won't try to pursue them, unless I see something between the lines, then I'll get them talking to me, derailing the pitch.

The act of stating an assumption that people do business in only in a certain way is actually a "blanket statements." My comment was an alternative, an advice to those eager to hear the other side to this RFP story.

our proposals granted us an opportunity to explain ourselves and our understanding of the problem or assignment at hand

Then you did not actually participate in the tender process. You did exactly what I do: you derailed the pitch and took control over the engagement.

our greatest success in responding to RFPs is when we make some sort of personal connection with the prospect.

Same as above, tender is about the biggest offering for the least amount of money, while you knowing the prospect is a wedge in that scenario that gives you an advantage. See derailing the pitch.

RFPs suck. RFPs drain your resources and time. RFPs are designed to tip the power balance in the client/designer relationship in client's favour, so they could compare you and your services to others, then hire the lowest bidder.

There will always be somone cheaper and you won't wow a client if they don't understand the value you're bringing in to the table. RFPs are not a way to show them your value. They are one-sided and thus will only account for time and materials.

"simply responding to 1-2 RFPs per week can mean thousands if not hundreds of thousands of dollars in added revenue (over the course of a few years)."

I don't know about you, but last time I checked, my job was not a "RFP response writer" but a "product designer". I solve complex problems by dedicating my time to activities other than going through someone's self-diagnosis that will be wrong a lot of the time and writing a lengthy and time-consuming response that will be compared with others. You may as well throw your time into something else, like mowing a lawn in your back garden.

To the point. If you think of yourself as "just another designer", go after RFPs. There's nothing wrong about that, if you can make it work. I prefer to have real conversations about business with my prospects.

If I see the meaningful opportunity in helping a prospect with an RFP, I'll try to derail the pitch and get them to talk to me one-on-one, so I could better understand their problems, not go and nod to a long list of specification for their project, which is most of the time just a wishlist put together by people who have no idea what they need.

For goodness' sake, talk to your prospects. Replace shiny presentations with conversations, and make them understand how you can meaningfully help their business/cause. Do it well and the'll forget about RFP and hire you instead. The second best answer you can hear is "no". If you do, move on, don't ponder on it. You can't win them all, and you can't lose something you've never had to begin with.

I have an ASUS PA248Q, which is 24", made and calibrated for graphic design and photography. It works best over miniDisplayPort connection (MacBook's HDMI is wonky). I think it should be around $300, but IMO it's best to throw in $40 more to get it. Exceptional display.

I have a tip for you: set the right expectations up front. What I mean is "don't promise what you can't give". If your process is agile, don't give your clients an impression it's as straight as an arrow.

As for communicating your thought process on design decisions, you have to present your work in the right way. Sending off mockups and asking "what do you think?" will set you up for a failure.

Actually, some time ago I wrote a handy piece on what you might just be looking for: http://matthewmorek.com/blog/the-user-experience-of-client-relationships. Let me know if it's of any use to you.

I think the closest one to your expectations might be elementaryOS Luna: http://elementaryos.org

It has a familiar interface, nicely designed and very easy to use. I would recommend it over any other distro for desktops.

All you’d have to do is add your favourite apps, such as Chrome, FileZilla, Sublime, etc and be on your way.

Nevertheless, I don’t think Linux is a good platform for web designers. Don’t get me wrong, I’ve worked on Ubuntu for a long time, but “designing” so to speak is not entirely possible due to lack of certain “industry-standard” apps, such as Photoshop or Illustrator.

But (it’s a big but), if you design your websites in the browser, then I think Linux may be one of the most comprehensive environments for this task, as it’s the only platform that has core parts used by majority of all web servers around the world. Setting up LAMP is a breeze on a Linux distro.

I use Golden Grid System, by Joni Korpi: http://goldengridsystem.com

It’s a responsive grid system that adapts to a given screen size by using percentages to calculate columns, gutters and the baseline. It’s also darn easy to use and very effective.