Casting such a broad net with the word "doubt" suggests that all questions are argumentative. But in fact, almost none of the questions listed here are necessarily expressions of doubt or the basis for an argument. They are expressions of seeking understanding, which is a designer's job.
A designer who is not a question machine can only ever put lipstick on your product, not really make it better.
Ditto - these are exactly the questions that must be asked, frequently:
> he asked “one of the good ones, or one of the bad ones?” A designer on his team — a “bad one” — asked too many questions. Questions like “Why are we building this now?” “Are we sure this is the right problem to solve?” “Why don’t we approach the problem in a different way?”
Calling those questions 'doubts' just doesn't seem quite correct.
In the best teams I've worked with/on, designers [1] aren't afraid to frequently ask these questions. I have yet to see a case where that's been a problem. Quite the opposite - far too often, there aren't enough deep / 'stupid' questions asked, especially at the outset & middle of projects.
I like to think I'm pretty well read, and I read mostly used paperbacks. But, aside from the universal question mark, I have never seen the markings you would prescribe for all to use. I have my own system involving brackets and post-its that suits me just fine.
My point is, it's hard to generalize reading requirements. I couldn't possibly write an extension to enable my markup style, because it changes to suit the book I'm reading. That's why electronic will never replace paper for me. Except for my trashy romance novels.
And not to thread sit (but since we're the only two people here right now) let me re-add a point which I removed from the OP because it was a hair over 2000 word limit--I bought the DPT-RP1 to read research papers, technical books, and non-fiction/text books at 100% size.
Responding to your comment about suggested marginalia set, its not intended for every type of text. But in the above mentioned context, the tags I introduce in the document (q, r, t, d) when performed with a grep search on plain-text files I have for notes on these technical books, I can generate quotes, references, terms, and definitions for over ten years of reading in under 5 seconds. That's darn useful.
Adler and van Doren begin their book with the importance of defining terms. You can't understand a book if you don't know the terms the author is using. I would argue that universal to all texts. The Kindle has a great dictionary feature which supports this idea. When it comes to technical books though, many terms are not defined in the standard dictionary.
For paperbacks, I use a Kindle Paperwhite, and that's a great product if you don't mind the MOBI format.
The market for these products still isn't clear to me. The prototypes they produce are always super unrealistic. And to get anything remotely usable for e.g. user testing, you end up spending huge amounts of time and often writing code. So why not just write code?
Couldn't agree more. I've spent a lot of time trying to explain this concept.
I do think the author has overlooked another common reason that problem definition gets overlooked: people simply conflate problems and solutions. Most of the "problems" people bring to me are actually solutions to some assumed and unacknowledged problem, e.g. "the button should be bigger." This preempts all critical evaluation of the problem and all of the alternative solutions.
Every proposal like this seems to assume that the web is basically the same as paper, and therefore should have tools that work like print tools. And this may be true for many marketing sites, which are effectively posters with download buttons. This is probably the kind of thing the author has in mind, because his wishlist doesn't include anything to do with interactivity, video, sound, etc.
But these are the best parts of the web! As much as designers want to believe it, a web app isn't actually a series of pictures. There are far more possibilities than with paper, and you remove all of those possibilities when you insist on designing like it's paper.
This is by far the biggest problem, web design with a print mindset.
A designer needs to understand and work with their medium and as long as they keep trying to represent the web (where their designs will be shrunk, enlarged, reflowed, include a time dimension and at any point entire elements can appear and disappear as a result of interactions) as a bunch of static 2D pictures they're working against their medium and are basically out of date. This was kind of understandable in the 90s when the concept of designing for the www was becoming mainstream. Around that time I was expecting it to take 5-10 years for the old generation of designers to fade out and for new people to arrive who would be trained and understand that print design isn't web design. I underestimated the problem, because that didn't happen.
It's now 2018 and I still regularly see job ads asking for developers who will create "pixel perfect PSD to HTML conversions". This is so wrong-headed.
I enjoyed the article, I remember rubbing sheets of Letraset transfer and literally cutting and pasting with a scalpel and Pritt Stick. The author is obviously clever and understanding of the current problems in web design. But I can't help thinking the main question the article asks is similar to "why is there still no point and click software with which I can write a high-quality novel?" or "why can't my beautiful rendering of a car be output as a working vehicle"
> It's now 2018 and I still regularly see job ads asking for developers who will create "pixel perfect PSD to HTML conversions". This is so wrong-headed.
I'm not sure if we've actually moved away from this or are moving more toward it. It used to be somewhat expected that a site should be functional without css (by putting the core content at the top), javascript and images but no one designs for that anymore. Half the buttons on the modern web are meaningless without a font served from a CDN.
And now we're moving toward a web built on canvas + web assembly, our user agents will have less control than ever. Maybe we can even cut out the middle men and render the psd directly.
> And now we're moving toward a web built on canvas + web assembly, our user agents will have less control than ever. Maybe we can even cut out the middle men and render the psd directly.
I know you're making a bit of a slight, but I won't kid you that publishers—frustrated by the fact that certain interactive features and desired visual structures require an understanding of the platform and code (even if they just have to hire people who -do-)—have started some move back to using print-version PDF's served to applications like Texture (recently purchased by Apple). Even with any compression or download-size problems that might come along with it. The art teams and editors are all very happy to keep doing the same process they've been doing for ~25 years, after having another technological progression dangling in front of them. If they could just take the PSD, stick it in a black-box folder and have it come out in their publication on every platform they output to... I think they might dance in the streets. Or start drinking earlier.
Am a programmer who has worked with first-hand with such publications. And now doesn't.
I applaud you for being a designer who actually codes. I feel that a true designer in the modern web must have a strong grasp of interaction design and how to build those experiences, and the consequences of various design choices, and to me that must mean that they can speak those ideas in code.
I am sick and tired of designers who are mostly glorified pixel pushers that throw together something pretty, but give no thought to edge cases or application states that force their designs into becoming ugly or having a poor interaction, or just becoming downright unusable, all because they rely on shallow and antiquated schools of thought that were born out of the paper and magazine media industries. Pretty, but rigid designs.
> I am sick and tired of designers who are mostly glorified pixel pushers that throw together something pretty, but give no thought to edge cases or application states that force their designs into becoming ugly or having a poor interaction, or just becoming downright unusable, all because they rely on shallow and antiquated schools of thought that were born out of the paper and magazine media industries. Pretty, but rigid designs.
I love working with designers who know they have no idea how to code, admit to having no idea how to code, but persistently work with the developers to ensure a smooth hand off of designed assets. Everyone's job is easier when they attempt to understand the other team member's job and tasks as well. I don't expect everyone to understand how to code but I don't think anybody likes working with someone who makes their job harder.
I agree with your latter statement - I've worked with a few teams now, and the best output always comes from teams that have designers with good foundation knowledge (i.e., of the psychology of design, alignment, balance, colour, gestalt, typography, white space etc - they could be highly effective print designers as well), who work closely with developers with deep understanding of the medium, where both sides are reluctant to compromise, but understand where they need to.
For the former though, I actually wish more designers had better knowledge of the "shallow and antiquated schools of thought" from the print world. A lot of that was born out of decades of iteration, and many of the toys that the web gives us aren't actually very useful for the kinds of content that many of them are tasked with publishing.
While I agree with you, from my experience, it seems like something that is more often normal to have knowledge of for older designers but seems like more of a passion for young designers to fully grasp as they may have to go out of their way to acquire such skills. I've found great people to work with of all ages but if they don't have coding skills and understand the evolution of graphics into interfaces or web assets than it becomes more and more difficult to continue working together on tight projects.
Unfortunately I rarely come across designers like this. It seems many designers prefer to be more like “concept artists for apps or interfaces” and leave gritty implementation details for the developer to figure out, rather than be actual designers who can think within development constraints, and consider all edge cases and state changes over time.
> Unfortunately I rarely come across designers like this.
Perhaps that's because "designer" is just a label that anybody can use, as opposed to e.g. an "MSc industrial design" which is someone with proper education.
I understand your sentiment but I will respectfully and strongly push back on the idea that if you don't code you're just pushing pixels.
You're ignoring the other aspects of design; research, testing, etc. Just because I don't code doesn't mean I don't understand the ramification of what I put down on 'paper'
I have coded in the past but I chose to let that skill drop as it takes practice and time.
By example, here's an overview of my methodologies. In fact, I call out how I can save coding time by iterating ahead of the dev.
I've worked with some talented designers in the past, and this rings true every time. They are often seen as great designers because they don't compromise, and the result of that is a happy designer, a not-so-happy client, and an unhappy development team. It's been almost shocking at times how little some of them have known about basic web standards, and how leading design teams have been built by people that would consider things like mobile-first to be "a fad".
I am also designer who codes, and like the author was classically trained but switched to digital medium. You are hundred percent right, designers who cannot comprehend UX part of the medium will never be able to deliver interactive experiences, they always will see web design like it was in early 2000, visual first. But there are small portion of us that uses design language for functional purpose, we care for UX first. The visual part of designing a layout is moving away from focus, its more important to make original illustration, compelling video or audio. PS> The funny part is that those print layouts are broken in current web with 80 percent mobile web consumption:)
A friend of mine agrees with your position and has built a business out of crossing this great divide between print and the web and actually I think his toolset is exactly the kind of 'DevTool for Designers' that this article is calling for .. so I'd be quite intrigued what other designers think of it.
(I'm just a friend of the founder of h5mag, and would love to know what isn't DevTools'y about h5mag, from a developers perspective. Disclaimer: I'm a developer...)
I think there's something to be said for the "it suits me" perspective. I had a similar conversion to fitness at the same age (though not running). Everybody also told me I must have such will power, but it really just suits me.
But maybe the real lesson was that if I'd chosen running I could be a famous author.
A designer who is not a question machine can only ever put lipstick on your product, not really make it better.