Reputation
29,257
Next tag badge:
125/100 score
19/20 answers
Badges
3 48 89
Newest
 Nice Answer
Impact
~943k people reached

1h
comment The coding monkey dilemma
@PariyaKashfi I've always argued that an organization hasn't fully succeeded with UX integration until they've gotten rid of their UX team. :) By that I mean that UX really should be something everyone is involved with--not just a particular team. I know it's an idealistic way to look at it, of course. The reality is that yes, you typically need a UX team to advocate for it.
1h
comment Shouldn't we separate UX from 'UX integration'?
@theotherone I think that's true of most professions. It's not so much what you know, but how well you sell it.
23h
comment How to Extend Mobile Web App to Tablet Size
This is too broad of a question. There are many specific ways, but it's all dependent on context: what the app is, how it's built, who it's for, etc.
23h
comment What is a sans-serif font that still clearly differentiates similar characters like: l 1, i etc
Look through some fonts designed specifically for writing code.
23h
comment The coding monkey dilemma
I agree with this. To take it a step further, I'd say the issue is over specialization. In orgs that hires 100% specialists, and 0% generalists, you really end up with a bunch of assembly line monkeys.
23h
comment The coding monkey dilemma
@Okavango I think what causes these problems is having completely separate roles and responsibilities. UX should be a collaborative role. It's UX, it's Business, it's Dev.
1d
comment The coding monkey dilemma
@PariyaKashfi that is very true. Alas, it's still the correct solution. Often working in a large company is a constant game of catch-22 :)
1d
comment The coding monkey dilemma
+10 for Lose the Silos. No, wait. +100!
1d
comment The coding monkey dilemma
I like this. I'd maybe go a step further with 'good developers' and say a good developer not just defers to UX but actively collaborates with UX. (and the reverse is true as well...the more UX and Dev collaborates, the better then UX in general)
1d
comment The coding monkey dilemma
@R.Barzell that's fine, but I think that heavily depends on process. In an Agile process, dev needs to be part of that creative thinking group as much as UX. In waterfall, dev tends to be simply told what to do (for better and worse).
1d
comment What is the most important for customer in terms of content?
There's no real specific answer to this other than "The content you have should be relevant to the user's needs and wants"
1d
comment How long should automatic doors delay closing?
They should stay open long enough for a person to pass through.
May
18
comment On forms, is inline placeholder text better than a label outside each field?
It's really important to point out that the Material Design example is not using placeholder text. It is using labels.
May
14
comment 'Fountain well' style of software development
"less unhappy" is maybe a safer way to put it. :)
May
14
comment 'Fountain well' style of software development
I wouldn't blame Agile on that, but rather how they are integrating UX into it. A lot of organizations (mine included) created an Agile process that didn't take UX into account. They now try to bolt it on and it doesn't work really well. Look into "Lean UX" which is an attempt at addressing this issue.
May
14
comment 'Fountain well' style of software development
Keep in mind that Agile is meant to handle exactly that...changes in business, technical and user requirements. You may not need to reinvent the wheel (though that's fun to do too).
May
14
comment 'Fountain well' style of software development
@MichaelLai to me, that sounds like typical 'enterprise process'. I work in an org that does the same thing. Often business requirements are written AFTER the UI is halfway built. I don't have a solution for that other than to say "Lot's of big companies simply have really bad processes and there is no magic bullet to fix it." :/
May
14
comment 'Fountain well' style of software development
Finally (maybe this should all be re-written as an answer!) you aren't totally off the mark, though. What you can do--even if you don't change the entire process--is to encourage a decoupled MVP framework. Have data not be directly coupled to UI output. That will give you the most flexibility.
May
14
comment 'Fountain well' style of software development
Ideally, however you do it, it's important to realize the end product is a complex one from front to back and the best way to hedge your bets towards success is to make sure that you aren't locking any one 'layer' of the system before the other 'layers' are built. The reason waterfall usually fails is that things always change. Agile came along to try and make that fact part of the process. Building the entire back end sans UI is, IMHO, as likely to fail as designing the ehtire UI sans back end. They have to be built in relation to each other (and each has to be willing to adjust as you go).
May
14
comment 'Fountain well' style of software development
It depends on what you mean by 'design'. In my book, development is design as much as UX is. You can't really develop something without also designing it--whether that's the developer or UX person or business lead or whoever. Ultimately, a prototype is a design. So, based on your last comment, I think you're actually referring to Agile. Get something built first then make it prettier as you go. (Also known as MVP: Minimal Viable Product)