(Disclaimer: I'm a designer and I'm probably very biased about the matter)
In my opinion it's very often a matter of expectations.
When a lot of design decisions are taken by a bunch of people, from management, engineering and marketing, including a designer would simply mean having one more person to compromise with. Companies working this way tend to have designers focus more on making the product look good, thus this dribbblisation of design. On the other side, engineering has historically been expected to deal with design when building products, and nowadays a lot of engineers have learnt how to design on the field. This reinforces the view that designers are only useful to make things look good. Lastly, the tools we use in design are really easy to use, anyone with a couple hours to spare should be able to create some stuff with most of the available tools. With that, it makes deciders think that the only difference will be a matter of taste.
A lot of designers can actually do more than that, the basis of their job is usually to question things with the perspective of the user: "Does it make sense to do this? Is it really useful to have that amount of customisation? How much information do we need to see?" Most of the time the solutions are stupidly obvious, or they're chosen based of how complicated it makes the system, or how costly it can be, and that's where experts add a lot of value.
All in all, if all you need is to make stuff look good, sure a dribbble designer is probably a good fit, just don't expect them to automagically make the product usable. If you want someone to work on your experience, you should probably have your designer work on the problem instead of having them "upgrade" your solution.
Just like how the engineering field is, the design field is really diverse with people doing different things, differently.
This. I'm not a designer, but my wife is (we met in a design studio I was prototyping for). We were just having this conversation yesterday about how design is "appreciated" in her company, basically going through every point you listed above. It takes a huge cultural change in a company to make something better than "design by engineer" desirable. Many companies want jack of all trade generalists who can code a bit and design a bit, meaning they can be reassigned easily enough to where the work happens to be at the moment. But at the end of the day, it's all mediocre output (though sadly, it is considered acceptable).
And then anyone who plays around with photoshop or illustrator for a few days seems to think they are ready for a visual design career (and interaction design is worse!). Who needs design school? So people encounter so many bad poorly trained and experienced designers that their expectations of the profession begin to be lowered. It is frustrating for those who actually went through hard work to become skilled and experienced UXDs.
I'm personally a PL designer and see the same issues in our field (well, it is very niche, and anyone who can write a compiler wants to design a language....).
Communicating information clearly was a big reason for Swiss style's ultra-clean aesthetic. It's come back in a way as flat design, but designers should heed the advice that looks pretty doesn't equal good design.
My main grievance with modern designs is low information density. Fonts are getting bigger and lots of whitespace is added between blocks. This works great for articles (as an example, medium articles look gorgeous and are a joy to read) but just about anything else is less usable when fewer bits of actual information are on the screen.
Ironically, one can also speak of UX-isation of design. I would define it as misguided thinking that the designer knows my problems better than myself. Take "you should take your umbrella" weather app. The information density is exactly 1 bit per screen which is abysmal. What about my jacket? Or what if I want to play badminton? Just give me the temperatures and wind info dammit.
Yeah, that's a big problem. I've worked with many UX people over the years, implementing their strongly held ideas and watching the metrics of user behavior afterward. My reluctant and painful conclusion is that they don't really understand users, it's all self deception. Though they do have good visual design skills.
Maybe the UX designer's job should include more statistics and analysis? It's not enough to draw mocks for engineers and do a usability test now and then.
If the UX people you've been working with haven't been doing post-implementation statistics and analytical measurement leading to refinement, then they are not UX people. They are visual or interaction designers playing at being UX people.
Unfortunately, the hard truth of it is that most "UX people" are in environments where the post-implementation cycle is ignored. For as many companies out there that claim to embrace the "UX process," I'd say that well over 80% of them don't actually embrace it beyond feature release.
I think one of the reasons here is that a lot of UX people don't work on products, they work on projects. And once you've handed in your deliverables, you move on to the next project and never ever look back.
> Ironically, one can also speak of UX-isation of design. I would define it as misguided thinking that the designer knows my problems better than myself.
It's not that the UX guy knows it better than yourself, but he strives to be able understand it and then to state it more clearly, in an actionable manner. I don't know the call-center operator problems better than he does, but I was able to identify the pain-points and improvements more clearly. While the user will know the problem way better than I do, I can't expect him to systematize and conceive solutions, as well as ways of measuring them.
That's actually what most UX methods tend to to, nowadays. Instead of asking the users, the UX guy will observe (e.g. do job-shadowing).
Ok, I think we all agree that UX design when done properly leads to a better product ;) Maybe the problem is that the field as a whole became more mainstream in the recent years and thus more susceptible to Sturgeon's law. Hence the negative experiences that I am talking about.
I agree. I don't wish to sound overly unkind to an entire discipline here, but I think in recent years there has arisen a perception that UX is a job which pays well and doesn't require any particularly hard skills: software development involves programming which is plainly quite challenging (and maybe requires being good at maths), design is very subjective, brutal (client feedback can be soul-crushing) and often laborious, but UX is this nice fuzzy domain that anyone with an interest in the web and apps can launch themselves into without much prior training or experience.
At least, I've spoken to a few people who feel like that. And I've worked with quite a number of UX people who didn't really seem to have any skills I could easily discern as being useful (but definitely could produce reams of wireframes that made absolutely no sense whatsoever - I remember one hapless UXer who made 10 pages of wireframes describing how he wanted a file upload dialog to work before a developer gently informed him that said dialog was entirely governed by the OS and we would have no control over it).
There's an independent certification being rolled out in London right now. Free udemy course and links to more info here: https://www.udemy.com/certificate-in-ux/
This is exactly the point. Your problem isn't the fonts or spacing, but the focus on prettiness to the detriment of usefulness.
There is always a balance between the two. There's room between the pain that is design without consideration of the information and the user, and information accessibility with no consideration for visual aesthetic.
I'm not sure we are talking about the same thing. As an example of what I am talking about - one of the internal apps at my workplace recently got a visual overhaul. The functionality is exactly the same. The previous version also had a designer working on it and he too tried to make the thing beautiful (according to what was fashionable then). But because the new version is made according to the current fashion so much less information fits on the screen. I suspect the same thing will happen if someone tries to fit the application into current UX paradigm of dumbing down the interaction.
Then the designer hasn't done his/her job. It should start with an understanding of what the user should be able to do. The story of the user interaction for every screen is vital. Without it, you end up with what you've described - something that may well be beautiful, but is deeply annoying to use.
And although the design doesn't display as much information, what are the needs for thi tool? Could some of the previously displayed information simply not truly be useful anymore? Was it adding visual noise and distracting from the main purpose of the visualization?
There are already countless weather apps, so people look to differentiate with variants that play on simplicity (rain being one example) or particular angles (one delivers weather with a humorous bent).
App developers will create whatever they think might stick. Further, if there were not merit in simplicity, such apps wouldn't be successful.
It's an amazingly common thing with developers in general and especially on here. Kind of a narrow focus on some superficially logical "best solution" along with complete dismissal of anything else based on arbitrary metrics they came up with.
More and more people want to have an opinion and they use medium to share it with the world. This is killing my narrow view of content creation because I am able to asess every single users motivation. With such clarity, I have determined they are, like me, all experienced professionals with 10 years experience putting their best work forward. Have you seen the comments section? People who don't have a masters in literature from Columbia are actually displaying positive sentiment about this trash. This industry is dead because medium, and other blogging platforms, exist and it is much easier to create and piblish content. People are doing this as a hobby, or semi professionally and I don't like it.
If you have to type </satire> it's probably not good satire.
After only a few paragraphs in, it became obvious that you've set up a one-paragraph strawman. His point is that the process of design is being traded and mistaken for making things look pretty. Seems like a reasonable argument.
Only Medium is neutral to writing, whereas his whole argument is that Dribble is NOT neutral as to the design process: it affects how its users approach design for the worse.
His core argument is that having your design admired in Dribble shouldn't be your idea of a successful design, but instead you should aim at its users, not other designers.
Look at it from the other side. If a designer were to suggest some of the more fundamental changes to how your product should work, would you genuinely listen to their opinions and suggestions, or are these critical decisions being taken by someone higher up in management?
Designers are often pushed into the rear end of the process in every sort of consumer product development (including software development). It is no wonder therefore that we end up with not only ugly but often unusable products. Big opportunities all around for a company that brings good design and better designers to the forefront of product development.
But it is just too damn hard for most people to let go of their ego where design is concerned. The whole design thing looks so intuitive and apparent right from the start that we can't believe we can't do it all ourselves, and, not only that, do it better that everybody else.
Proposing fundamental product changes takes solid grasp of what is called "product architecture" in the article, i.e. precise understanding of the concepts involved and the intricacies of their interaction. That means becoming a domain expert, knowing how to work with analytics and maybe even having a basic understanding of backend architecture. Most of the designers I have worked with (admittedly a very small sample) were content with muddled understanding from the point of view of casual user and so mostly drew pretty pictures.
I would agree. It gets difficult sometimes to implement a design from a beautiful looking mockup. Mainly because the design does not take into account most of the software use-cases. Then we go back to the drawing board again.
Which is sort of why I think designer who can implement design (in HTML/CSS/JS or iOS/Android) is ideal, as they are much more likely to have that sort of "product architecture" thought process; and being as closed as possible to the code which means it becomes easier to adapt the design.
Personally like Ryan Singer's approach to designing as he jumps back and fourth between HTML and Photoshop (https://vimeo.com/16814487), the design gets much closer to reality.
> Proposing fundamental product changes takes solid grasp of what is called "product architecture" in the article, i.e. precise understanding of the concepts involved and the intricacies of their interaction.
That's exactly the point. Assuming your product will be used by humans, a designer (a real designer; not a dribbbler pixel-pusher) is way better equipped - in terms of methods for understanding users and context - than a engineer or a manager.
In my experience, designers are clueless obstructionists. They take months to mull over trivialities, then finally come up with an obvious solution that anybody could have seen from the start. Maybe I just got some bad designers though.
Being a professional coder who is now studying design one thing I've discovered is that most people underestimate the scope of good design and seem to want to narrow the designer just down the prett visuals, discounting anything unseen (eg process).
Another difficulty is that much good design is obvious in hindsight, think iPad but the act of whittling away what is unimportant is a key part of the job.
Or yeah maybe you've just dealt with poor designers.
This sort of flash-over-substance internet feedback loop has cropped up in a number of different arenas. Five years back or so I was on the staff of a website that was created primarily to promote Halo multiplayer maps, to receive feedback, and to feature the talented creators in the community.
A great deal of excellent maps went through the site, but I became increasingly upset over what I saw as a shift towards presentation-over-substance with the original posts. If you wanted people to play a map, it soon became all but required to have a massive original post, with screenshots and "action shots" and flashy headers to catch people's attention. The focus became more on these OPs than the maps themselves. There was a movement towards standardising the process to reduce the flashy bloat, but it was unable to affect the changes I perceived as necessary, so I ended up leaving the community.
How can issues like these be fixed? Can they be fixed, or is it just a bug in the human code that superficial beauty halo effects everything else out of consideration? Perhaps communities of a certain size eventually reduce to a certain lowest common denominator appeal. I'm not certain.
In general, as long as the community continues to value substance and the principle of the most charitable interpretation, it will survive. When we start seeing memes and catfights, that's a sign the community is dying.
I assume you're talking about ForgeHub? If so, we had a crisis of leadership more than anything else.
We actively encouraged what you describe as our short comings. It was in our map posting guidelines that you include lots of screenshots and a well-written write up.
I don't think the issue lied in the community. The larger it grew the better the maps became.
Really the blame falls on me. I had a platform for distributing maps and I had the audience. What I couldn't do was grow up quick enough to really allow the site to reach its potential.
This article compares a community of Visual Designers (the ones you find on Dribbble) with 2 specific UX people.
A better comparison would be Dribbble vs IXDA, community vs community, one with the focus on form vs the other with focus on function.
If you look at it that way, the signal to noise ratio is honestly about the same in each community. A couple gems here and there, but 90% of the stuff I see or read on both don't seem to be solving anything.
I think of dribbble designers as who you hire when you know what the thing is going to do and how it's going to be organized. All else equal, I think there's something to be said about a product looking good. Hiring a painter to build your house makes no sense, but hiring a painter to paint your house does make sense.
I don't think these are the roles of a designer. But to explain why, I need to unpack some context first.
I've spent most of my career at the interface between marketing, programming and design. Marketers are increasingly having similar discussions about how they need to be more involved in everything to make sure a good job is done. Things that would traditionally be seen as PR or branding or would fall into media or even product design, are increasingly being encroached on by marketing.
At the same time, in the development camp I see people wanting to be part of marketing and creative meetings to talk about feasibility, or to be involved in higher level strategic meetings to talk about technology and its role in business.
Just as designers want to be involved in things that aren't the shiny bit of design, I think we're seeing an evolution in how businesses will work more generally.
Traditionally, the role of orchestration was carried out by middle management; people who had solid skills in the areas of those they managed and who could talk technically to them, but were also good leaders with solid soft skills. People who could coordinate teams to produce outcomes.
Increasingly though it seems like that model is being moved away from, to one where representatives from various departments get together to decide on things where there's overlap. So product, business strategy, development, and design might be holding regular meetings to discuss planning and execution. Think of this as a cross-business scrum if you like.
I think the problem is that it's just very hard now to set a boundary on where one thing ends and another begins. Application architecture is in the realms of development, answering problems defined by product people, made beautiful and usable by designers. There's overlap. But whilst that means design needs to be in the room, it doesn't mean they need to own it. Corollary: design is in the hands of designers, but dev needs to be in the room to discuss time to implement suggestions raised.
There's an increasing need for facilitation of discussion and understanding cross a department, but I don't think that means we need to put everything in the hands of design, or dev, or anyone else. There's value in specialist teams with deep domain knowledge. But better comma at the fuzzy edges is certainly required.
> I think the problem is that it's just very hard now to set a boundary on where one thing ends and another begins. Application architecture is in the realms of development, answering problems defined by product people, made beautiful and usable by designers.
I think you have a misconception here. A designer is not a decorator. Making it usable (and beautiful, as you call it) is way below conceiving the product, in a true designer perspective. Software people don't like to admit it, but designers are much more prepared and educated to conceive a product for humans than engineers or managers.
There's a whiff of the 'no true Scotsman' fallacy about this though. The OP was suggesting that some designers are focusing on the decorative aspects of design because that's what looks good on a Dribbble profile. Given that 'making pretty designs' is a learnable skill and that at least some companies will hire people based on that skill, you're going to find a non-negligible number of people employed as designers whose primary skill is in making things that look good, rather than things that work well.
The other problem is that even if a designer is conceiving the product holistically, if that design is communicated in the form of PNGs or PDFs, it's unlikely that their vision is going to be understood correctly. In a collaborative environment, everyone needs to be part of the design process, because many aspects of good design require an understanding of the thought process that leads to the product as an outcome. The idea of the designer as a visionary who conceives the product and then hands off designs for other people to build is a seductive one, but it very rarely works.
No, I think in many projects designers are decorators - which leaves no one in charge of the user experience from the point of view of the user.
In the same way that a full-stack Linux expert isn't going to understand how someone without 5+ years of command line experience approaches a computer, a trained designer with an experienced eye is always going to struggle to point themselves in the place of a naive user.
Good UI needs to be tested for design assumptions and for user taskflow. The testing needs to be repeated every time changes are made. For any business with a web site that sells to customers, this is at least as important as unit tests in code.
IME designers aren't often interested in this. Some are, but many simply don't get it. And even if they are, there's pressure to see UX as a machine for driving conversions (hence the same Bootstrap template with the same social proof and the same calls to action everywhere), and not so much as a way to make the customer experience more positive.
The proof is that many sites are broken in some fundamental way. I was on a logistics site yesterday trying to organise a redelivery, and the site simply didn't do what I needed. The graphics were pretty, but it obviously hadn't been tested properly, and many elements were broken.
Yesterday's example was unusually bad, but similar issues aren't unusual.
> No, I think in many projects designers are decorators - which leaves no one in charge of the user experience from the point of view of the user.
I agree. That's my experience in this industry, and in big projects. Designers are hired to make things look pretty.
> In the same way that a full-stack Linux expert isn't going to understand how someone without 5+ years of command line experience approaches a computer, a trained designer with an experienced eye is always going to struggle to point themselves in the place of a naive user.
... but with this I can't agree. It's not a reasonable comparison. The full-stack Linux expert won't understand the user mostly because it's not his job to do so. He doesn't have the knowledge and methodology to get to know and understand the user (as well as his context). The UX expert, on the other hand, should be trained specifically to do this in the most systematic and unbiased way possible. He doesn't need exactly to role-play the user (frankly, I don't like this conception of UX, but that's a pet peeve), but he should know and understand him. It's not "I think the user will like this", it's "I know users want this".
> Good UI needs to be tested for design assumptions and for user taskflow. The testing needs to be repeated every time changes are made.
And in this we fully agree again. All the knowledge the UX expert can harness about the user and his context should be validated, as early as possible.
I agree completely. That's where the fuzziness comes in. How something works is part of the design. It's also part of the development. It's also part of strategic business decisions (in scoping especially so). I'd put the user story and experience work more in design and product camps than in development. But the architecture for translating that into something that's interacted with is then dev or engineering, which also has overlap into design and finance and other areas. The output of that then leeches into design and business analytics and finance and so on.
My contention isn't that design is relegated purely to making stuff pretty, but rather that, just as design is more than that, so is dev and so is business strategy and everything else. It's hard (and indeed counter-productive) to compartmentalise any specific discipline.
The weather app example at the start annoys me. I want a weather app for data, not decision making. I want to consume a couple of data points easily, for various needs. 7 of those 8 apps do that.
Rain amount (bike or bus today?)
Wind amount (can I bodyboard today? Rain coat or umbrella?)
Temperature (gloves for the wetsuit? Jacket when biking?)
Sun amount (can I do a cliff walk this weekend or will the trail be muddy?)
Etc... I don't want an umbrella app, a surf app, a walk app, a bike app... I just want some data that I will use in a multitude of ways.
My 2 cents, as a former visual designer, now senior UX designer - Dribbble is a place where lots of pretty baubles are on display, where flash is valued over process, and where it's very hard to get a sense of anything other than the showcased designer's visual acumen.
When I'm interviewing a designer, I don't take it as a positive or negative that they have a dribbble account. If they're interviewing for a position that is primarily visual design, I will peruse their stuff there just to get a sense of their style and capability, but not as a final deterministic factor on their hireability.
Dribbble was never really meant to be a place where people showcased their process, just a place where they could throw out a quick snippet to get reactions. Visual designers find that extremely helpful. If you're not versed in the ideas of typography, color theory, moodboarding, concepting, or any of the other methodologies and tools in a visual designer's wheelhouse, then looking from the outside in at Dribbble can make it seem like a world filled with trite, inefficient, fantastical non-reality.
You're not alone in this. Even I, as a former visual designer, have to tell myself that when I go clicking through Dribbble. It's not a place to showcase fully-polished, finished products - it's not a product marketing site. It's not a place to showcase the messy process of product design - it's not a portfolio site. It's a place where people can toss out ideas and get feedback on the micro-points of it. The colors, they typography, the alignment. Start to expect anything more and the model of the entire site falls apart.
For better or worse, Dribbble is not built to scale as a place for the critique of the entire design process. I think that's where this article gets it wrong. There are plenty of things to critique the site for - the lack of real meaningful engagement, for example, or the highly exclusive invite-only nature, for another - but fundamentally the OPs of this article are projecting thoughts and ideas about what they think/want Dribble to be vs what it actually is.
TL; DR: Dribbble is a place to showcase digital visual art and design artifacts, not a meaningful UX or UI portfolio catalogue.
I don't know about this. I think it's wholly possible that people derive inspiration and perspective from Dribbble, Behance and similar sites, and use that inspiration to attempt to solve actual business problems in UI/UX, the specifics of which are never posted to Dribbble, either due to NDAs or more likely, because it would be incredibly boring for the average Dribbble user to look at.
I don't believe Dribbble has portrayed itself as a site to showcase business case studies. A lot of the time, it's simply a repository of design samples or off-work personal projects. And I'll admit, after a long day of looking at dull wireframes, it's simply a relief to look at a fun UI mockup animation, even if it might not work in a real-life production app.
The idea "form follows function" (or mission or vision) is as old as modernism itself. Its linear approach, from "vision" down to "visual", neglects an important aspect of design process that is dynamic in essence. Often interaction design redefines a product's core function, or a visual design so beautiful that it becomes an integral part of a product's vision. I'm not convinced that product/design process has to be like a waterfall or a tree or a loop. It can be more like a web too.
These days I've reviewed so many portfolios with post-it notes and hand-drawn flow diagrams. Don't they look all the same like dribbble too? Don't they all tell the same story, over and over?
I find the article's tone overly dismissive, and prefer to think of Dribbble as a GitHub for designers: a place to show off, discuss and hone their craft, and seek inspiration.
In my opinion it's very often a matter of expectations.
When a lot of design decisions are taken by a bunch of people, from management, engineering and marketing, including a designer would simply mean having one more person to compromise with. Companies working this way tend to have designers focus more on making the product look good, thus this dribbblisation of design. On the other side, engineering has historically been expected to deal with design when building products, and nowadays a lot of engineers have learnt how to design on the field. This reinforces the view that designers are only useful to make things look good. Lastly, the tools we use in design are really easy to use, anyone with a couple hours to spare should be able to create some stuff with most of the available tools. With that, it makes deciders think that the only difference will be a matter of taste.
A lot of designers can actually do more than that, the basis of their job is usually to question things with the perspective of the user: "Does it make sense to do this? Is it really useful to have that amount of customisation? How much information do we need to see?" Most of the time the solutions are stupidly obvious, or they're chosen based of how complicated it makes the system, or how costly it can be, and that's where experts add a lot of value.
All in all, if all you need is to make stuff look good, sure a dribbble designer is probably a good fit, just don't expect them to automagically make the product usable. If you want someone to work on your experience, you should probably have your designer work on the problem instead of having them "upgrade" your solution.
Just like how the engineering field is, the design field is really diverse with people doing different things, differently.
(Wow, that was a long rant, sorry about that.)