I’ve only worked once with a UX person and all they did was order other people to produce design documents before any software was written. Like, he didn’t design anything himself and didn’t even critique others’ designs. He made over $300K and eventually left for a job on the west coast making twice as much. He stopped talking to me entirely after the client had me write a prototype TV guide-type app for Blackberry. I created it entirely myself and the client loved it and wanted it released to the public exactly as it was. UX guy insisted (client didn’t care at all) that all software needed a design document before any coding could take place, so he was forced to order somebody else to produce a design document for my app which already existed. He wouldn’t even look at me when we passed in the hall after this.
I assume that this is not actually what a UX person is supposed to be doing, but I have no idea what their real job is.
The issue with newly emerging and poorly defined professions is that I could apply to any arbitrary position of that title, pretend like I’ve got expertise in a universal structure for it (managers love structure) and sound vaguely knowledgeable (hiring managers often don’t know the subject matter).
By the time they’ve figured out that I’m not actually contributing anything of value, I’m taking off to other pastures that aren’t about to wilt, my experience serving as selling point for the next sucker to hire me.
Of course, the people I just fucked over have no way of telling whether that’s me being a fraud or whether it’s the entire profession that’s actually worthless and overhyped.
Some, like you, err on the side of “I assume that person was a cunt”, while others default to “UX is completely useless”.
UI design existed for forty years at least. The problem, of course, is that few people understand what a designer actually does, unless they’ve met a really good designer.
UX designers will be quick to point out that it’s a related, but separate role from UI. The experience you have with a product starts before actually using it and lasts after you stop.
For example, your product’s presentation sets expectations, and so does the context in which you look for it in the first place. If the actual product doesn’t deliver on that, it’ll lead to frustration, no matter how good it may be at what it actually does. (Of course, if it turns out to be great, that may compensate for the disappointment, but “they liked it anyway” is not exactly what you want to gamble for.)
UX also covers the flow of actions, such as reading comment replies and replying in turn. I need some way to know that there is something worth reading and replying to (which the UI then implements as a red badge), that intuitively leads me to the thing in question (so the UI puts the badge on the Inbox, which then opens to the unread messages) and enables me to do what I want (with buttons, gestures or a menu, or all three).
Often, good UX requires a good UI, and a good UI designer will have a solid grasp on the way users think and act too. They’re closely related and you’ll see many people fusing the two roles, because there’s a lot of overlap between “how do users think” and “how do I communicate what they can do”.
I just think that most UX designers share the UI design responsibility, so it’s not that distinct of a job.
Your initial comment above came off as hostile to UX designers, which is why I felt the need to reply. Afaiu UX design as a discipline, particularly in software, appeared around the nineties to early two-thousands, likely influenced by industrial design (namely Don Norman himself) — so it’s not quite an ‘emerging’ discipline, but it’s surely vague.
Your initial comment above came off as hostile to UX designers, which is why I felt the need to reply.
Nah, I’m married to one. I just share her grief over grifters wearing the title without actually doing the job well and giving the whole guild a bad name.
Incidentally, that might also be why I’m so aware of the distinction (on paper) between the responsibilities. As you say, the actual job is usually fused from both responsibilities, which makes sense because it skips a step between UX analysis and UI design.
I’m guessing that the design documents might’ve been something in the vein of ‘user stories’ (if I correctly recall their name), which describe what some typical users would want to do with the app, so that the actual UI design would focus on these features being available front and center. This is a very legitimate design technique, and a good designer should always question why any elements must be present in the UI and whether they solve the user’s goals.
This Blueman thing would definitely benefit from such approach, because right now it exposes a lot of technical details about which I don’t care, while simultaneously making my everyday operations with it inconvenient.
By the way, @[email protected], I brought up user stories in particular because they should be initially written or at least verbalized by either the target users or clients like managers. Neither designers nor programmers can know exactly what the target user’s needs are, or they may think they know but be mistaken — because they don’t have what’s called the domain knowledge, i.e. expertise of the target users.
Of course, another major tool in a designer’s workflow is testing with target users before release, including with rough mockups — so any misunderstanding of users’ goals and workflow can be caught in time.
For the context, I’m a dev who mostly does backend. But understanding design is interesting and helpful.
another major tool in a designer’s workflow is testing with target users before release
Lol you should have seen this UX dude’s face when I suggested doing exactly this. It’s hard to imagine an actual live human being saying “users don’t know what they want” but that is exactly what he said. It should be no surprise that this company routinely produced one-star apps, and also no surprise that the company was a routine winner of the Worst Company of the Year contest.
Yeah that dude was just a dick, but probably confidently, and in a field people don’t know much about, so he was able to get away with it.
I work with UX people frequently, and while they do love a good style guide, they’re usually more concerned with the overall usability, legibility, and accessibility of an application. They’re the people who (should) ensure your application works as expected and follows design and accessibility standards.
Ah, this reminded me of another reason this dude hated me. One of my responsibilities with this gig was ensuring that the client’s mobile apps passed accessibility testing. Making an app accessible is tedious work and every time we released an update the accessibility would be broken again. I tried to get this dude to bake the accessibility requirements into the design documents themselves on the off chance that the other developers would actually read the documents (lol as if) and make accessibility work from the get-go. He wasn’t having it and couldn’t be convinced that it mattered if blind people could use the apps or not. I had to sic the client (who faced enormous fines for failed accessibility tests) on him to get him to do it.
Heh.
Design documents are only useful if those deciding the design are making it and are ready before the coding starts.
And then there is this confusion of which “Design Document” one is talking about. It could be a UI/UX document or it could be the software design document, which would comprise multiple flow-diagrams, helping anyone pick up a project for maintenance and extension.
This kinda depends. User stories document the typical goals and workflow of the users with the app, and thus should come from the target users or at least the client like a manager. The designer is not qualified to make the user stories since they don’t know the business domain, as it’s called. But they know how to organize the UI for any particular goals.
I’ve only worked once with a UX person and all they did was order other people to produce design documents before any software was written. Like, he didn’t design anything himself and didn’t even critique others’ designs. He made over $300K and eventually left for a job on the west coast making twice as much. He stopped talking to me entirely after the client had me write a prototype TV guide-type app for Blackberry. I created it entirely myself and the client loved it and wanted it released to the public exactly as it was. UX guy insisted (client didn’t care at all) that all software needed a design document before any coding could take place, so he was forced to order somebody else to produce a design document for my app which already existed. He wouldn’t even look at me when we passed in the hall after this.
I assume that this is not actually what a UX person is supposed to be doing, but I have no idea what their real job is.
The issue with newly emerging and poorly defined professions is that I could apply to any arbitrary position of that title, pretend like I’ve got expertise in a universal structure for it (managers love structure) and sound vaguely knowledgeable (hiring managers often don’t know the subject matter).
By the time they’ve figured out that I’m not actually contributing anything of value, I’m taking off to other pastures that aren’t about to wilt, my experience serving as selling point for the next sucker to hire me.
Of course, the people I just fucked over have no way of telling whether that’s me being a fraud or whether it’s the entire profession that’s actually worthless and overhyped. Some, like you, err on the side of “I assume that person was a cunt”, while others default to “UX is completely useless”.
UI design existed for forty years at least. The problem, of course, is that few people understand what a designer actually does, unless they’ve met a really good designer.
UX designers will be quick to point out that it’s a related, but separate role from UI. The experience you have with a product starts before actually using it and lasts after you stop.
For example, your product’s presentation sets expectations, and so does the context in which you look for it in the first place. If the actual product doesn’t deliver on that, it’ll lead to frustration, no matter how good it may be at what it actually does. (Of course, if it turns out to be great, that may compensate for the disappointment, but “they liked it anyway” is not exactly what you want to gamble for.)
UX also covers the flow of actions, such as reading comment replies and replying in turn. I need some way to know that there is something worth reading and replying to (which the UI then implements as a red badge), that intuitively leads me to the thing in question (so the UI puts the badge on the Inbox, which then opens to the unread messages) and enables me to do what I want (with buttons, gestures or a menu, or all three).
Often, good UX requires a good UI, and a good UI designer will have a solid grasp on the way users think and act too. They’re closely related and you’ll see many people fusing the two roles, because there’s a lot of overlap between “how do users think” and “how do I communicate what they can do”.
I just think that most UX designers share the UI design responsibility, so it’s not that distinct of a job.
Your initial comment above came off as hostile to UX designers, which is why I felt the need to reply. Afaiu UX design as a discipline, particularly in software, appeared around the nineties to early two-thousands, likely influenced by industrial design (namely Don Norman himself) — so it’s not quite an ‘emerging’ discipline, but it’s surely vague.
Nah, I’m married to one. I just share her grief over grifters wearing the title without actually doing the job well and giving the whole guild a bad name.
Incidentally, that might also be why I’m so aware of the distinction (on paper) between the responsibilities. As you say, the actual job is usually fused from both responsibilities, which makes sense because it skips a step between UX analysis and UI design.
I’m guessing that the design documents might’ve been something in the vein of ‘user stories’ (if I correctly recall their name), which describe what some typical users would want to do with the app, so that the actual UI design would focus on these features being available front and center. This is a very legitimate design technique, and a good designer should always question why any elements must be present in the UI and whether they solve the user’s goals.
This Blueman thing would definitely benefit from such approach, because right now it exposes a lot of technical details about which I don’t care, while simultaneously making my everyday operations with it inconvenient.
By the way, @[email protected], I brought up user stories in particular because they should be initially written or at least verbalized by either the target users or clients like managers. Neither designers nor programmers can know exactly what the target user’s needs are, or they may think they know but be mistaken — because they don’t have what’s called the domain knowledge, i.e. expertise of the target users.
Of course, another major tool in a designer’s workflow is testing with target users before release, including with rough mockups — so any misunderstanding of users’ goals and workflow can be caught in time.
For the context, I’m a dev who mostly does backend. But understanding design is interesting and helpful.
Lol you should have seen this UX dude’s face when I suggested doing exactly this. It’s hard to imagine an actual live human being saying “users don’t know what they want” but that is exactly what he said. It should be no surprise that this company routinely produced one-star apps, and also no surprise that the company was a routine winner of the Worst Company of the Year contest.
Yeah that dude was just a dick, but probably confidently, and in a field people don’t know much about, so he was able to get away with it.
I work with UX people frequently, and while they do love a good style guide, they’re usually more concerned with the overall usability, legibility, and accessibility of an application. They’re the people who (should) ensure your application works as expected and follows design and accessibility standards.
Ah, this reminded me of another reason this dude hated me. One of my responsibilities with this gig was ensuring that the client’s mobile apps passed accessibility testing. Making an app accessible is tedious work and every time we released an update the accessibility would be broken again. I tried to get this dude to bake the accessibility requirements into the design documents themselves on the off chance that the other developers would actually read the documents (lol as if) and make accessibility work from the get-go. He wasn’t having it and couldn’t be convinced that it mattered if blind people could use the apps or not. I had to sic the client (who faced enormous fines for failed accessibility tests) on him to get him to do it.
Heh.
Design documents are only useful if those deciding the design are making it and are ready before the coding starts.
And then there is this confusion of which “Design Document” one is talking about. It could be a UI/UX document or it could be the software design document, which would comprise multiple flow-diagrams, helping anyone pick up a project for maintenance and extension.
This kinda depends. User stories document the typical goals and workflow of the users with the app, and thus should come from the target users or at least the client like a manager. The designer is not qualified to make the user stories since they don’t know the business domain, as it’s called. But they know how to organize the UI for any particular goals.