Things I, as a designer, wish more tech startups knew
the-pastry-box-project.net
the-pastry-box-project.net
in an early stage startup, you're still tossing around ideas and trying to find what fits with your target market. In that stage, you can't just contract out UX to a designer. You'll burn up all your runway doing so, as you iterate.
In my opinion its better to do UX internally, and coordinate with your designer for stylistic changes.
There are good designers who specialize in user experience, but those people are also good at marketable skills like graphic design, coding or statistics. Everyone on the team is responsible for good user experience. The existence of a person who does nothing more than "UX" is a process smell.
As a further aside, I also despise "information architectures" which these UX people always want to hammer out. To me, information architecture is a buzzword and total crap. I want to see high fidelity design comps. No more Omnigraffle low fi wireframes. (And especially no Omnigraffle wireframes as a deliverable to developers to code real UIs!)
Ultimately, the UX lead helps with product decisions by leveraging said user feedback to suggest incremental changes to the product. If they simply leave after the designs are "done" and never touch the product or app again, then their utility is marginal to an organization.
That's not putting "design" in the middle of "development". It's making sure that we're actually doing what we think we're doing - building something that works and gives value to the user.
What's the alternative - just hoping that we got it right?
Doing user study with the intention to iterate on the design after the development progress is already far into completion is failure of the designer. If the design is so weak that it hasn't been validated by users, then it is not finished yet, that's it. One has to straighten up the design and validate it with users first. And it has to be done -before- giving a detailed framework to the developers, and claiming that the design is good enough.
After the fact user studies to brush up the UI polish is fine, but that is not the core task of the interaction designer. It can be done by a different expert other than the designer if needed (a junior designer, a developer with interest in usability, etc.).
I've seen too many successful teams work otherwise to think that way any more.
In my experience designers getting the design "right" before handing it over to developers is often just as wasteful, and goes wrong nearly as much, as the developers kicking off at the start and expecting the designers to "make it nice" afterwards.
Business folk, developers and designers need to work together right from the start. Figuring out the best ways to validate the assumptions that we're making so that we can be sure together that we're building the right product. Sometimes that's user research, sometimes that's validating business models, sometimes that's building stuff.
I've a 40m rant-ish presentation on design & how it should be an ongoing process over here if you're interested http://www.infoq.com/presentations/Design-Never-Stops :-)
My specific complaint will be that the talk occasionally digresses to what UX is, how a designer should be a good citizen, and how developers can be nice, etc. I am not familiar with the context of the talk, perhaps the general track had to have such discussions.
Nobody would argue that there would be no need to update the interaction as the product ages. However, that does not warrant the persistence of a designer in the middle of the development process. I am not referring to small changes to accommodate UI conveniences, about a design that did not fulfill its promise in the first place. A product design should not go out of date before it is released. A major revision is another story in itself, and that should be taken as a design update, and should be planned accordingly.
It is true that software is the most malleable product material ever, but the temptation to count on that malleability instead of focusing on good design only brings about frustration both on the side of developers and eventually on the side of designers, and most importantly on the side of customers.
Perhaps there is a bit of distrust between designers and the developers, as the developer has the final say in what is going to be done and what will be ignored, in addition to the need to update the design a little bit as the real usage data flows in. Or, perhaps the blanks in product requirements is a lot bigger in startups vs enterprise in a way that would effectively get the product change drastically every 3 months. I have only seen iterative design work well in indie games and small-time mobile apps, but those really do not count, as they would only be considered as prototypes in an enterprise environment, and you'd probably go about doing that much prototype while designing your framework.
Wireframes are just one possible deliverable - a way of communicating the results of some kinds of UX work that include IA.
There's a lot of UX folk who hate 'em to - and would much rather spend their time working with the developers rather than waste a stack of time producing pointless documents.
See Jeff Gothelf's article on getting out of the deliverables business http://uxdesign.smashingmagazine.com/2011/03/07/lean-ux-gett... for example, or Google the stuff coming out of the Lean UX community.
A real UX person will be able to and should provide high-fidelity mocks of the entire flow, preferably with an interactive demo of some kind. They will certainly have design skills and preferably programming skills. However, those high-fidelity mocks are the last stage in the UX design process. If all you want are those final mocks then you are doing nothing more than asking for a new coat of paint, and what you really want is a graphic designer.
So, you're right, everyone on the team should be responsible for good UX, but it really helps to have someone who can slam together some mocks after the meetings, or whose job it is to come up with a completely new idea to solve our nasty onboarding flow problem. Because George, the guy who's in charge of making sure our DB doesn't implode under load? He might be able to help out with the UX, but he's already got a full-time job to do.
Your image of a UX person that produces no mocks, no prototypes, no designs, and just sits in meetings is a sad one. Those people should be fired, because they are not doing anything -- certainly not UX.
My point is that "UX Designer" is a largely unnecessary job description that is filled by quality execution in more traditional roles.
And yes, there is a huge difference between the two. UI/UXers need to have extremely strong graphic design skills (and for 98% of the projects out there, they will be good enough by themselves), but for a perfectly-tweaked, masterfully perfected paint job to layer over the final UX, you should hire a graphic designer for a final pass (Apple does this, for example). Similarly, graphic designers, if asked to design UI, will usually produce something that looks gorgeous and is completely unusable (or, more frequently, completely ignores the corner cases that end up being deal breakers).
Or perhaps you mean _product design_, which involves a terrifying gestalt of UI/UX design, technical design (eng), and market planning/vision (management, PM, ...?). The person (or people) in charge of that varies by project and company, but in the most successful cases seems to be either someone who is good at all three or a 2-4 man group of representatives from the three domains.
Terrifying, indeed. The people who obsess over terminology are, in my experience, often the same people who bring the least practical talent to the table.
Or perhaps you're implying that there is no difference between UI designers and product designers? Admittedly, sometimes those are the same person, but usually the person who fills the PD roll is a manager or CEO (if at a startup). They'll certainly consult with the UI designer (and eng), and they may design most of the product with the UI designer. Or they may not. Not necessarily the same job. It really depends on the people and the company.
If this seems like bullshit to you then...I'm sorry? That's how most of the industry works (at Google, at Apple, at ...). There are not these strange creatures called "designers" who do everything and have all skills (some do exist! but they are shockingly, painfully rare. And they're usually not in charge, so it's hard for them to do product design).
"If a UX designer produces mocks and designs, they're a designer. If they produce software prototypes, that's called an engineer."
You must know both to be a real UX designer. That's the person you want, and yes we're expensive. We may not be the best at either one, but our ability to bridge the gap between the two gives us a unique perspective that allows us to make experience improvements.
In the development world we have "developers" or "engineers" - which include all of: * back-end coders * front-end coders * devops * folk focussed on building automated tests * folk focussed on tool development to support the rest of the team * database experts * etc.
... and we're also quite happy to have people be good at bits multiple categories and be
In the UX community we have: * interaction designers * graphic designers * UI designers * content strategists * usability testers * user researchers
And like the dev world there are people who are good a bits of multiple categories, but there isn't really a good general identity. As I said "designer" is often seen as just graphic design. UX Designer is a ghastly clumsy phrase, but at least it doesn't suffer that problem.
Real UX Designers are not process managers - they are folks who are vital to any product development because it's their responsibility to think about and WORRY about user needs, user goals, and user objectives and then design a product/site/app that meets and exceed these user objectives.
This thinking and worrying results in design documents as high-level as application architecture or as layout specific as UI sketches and fully baked UI mockups. Within the UI mockups, they're in charge of naming conventions, layout, structure, content hierarchy, and so forth.
This thinking and worrying also results in clickable prototypes (usually in the form of HTML only prototypes or InvisionApp prototypes) that brings together the user flows, architecture, and user goals into something the entire team can wrap their heads around.
Finally, the UX designer is instrumental in testing and validating design decisions and product design decisions in a live app. This involves knowing what to test, how to test it, and then iterating on the designs to make sure the feedback from users is reflected in an updated UI or a revamped flow.
Prototypes and architectures divorced from working code are the kinds of thing that bog a project down and get in the way of people doing the real work, i.e. making the actual product.
I know what programmers do and I know (more or less) what visual designers do and I know what the decision-maker for a product does. I don't know what a "UX Designer" does, other than claim to do all the product thinking. In my experience, they mostly talk vaguely about how important they are.
I agree that everybody should be doing it. However - there are elements of it that are skilled and tricky to pick up. Having experts around is handy. They can do stuff better, help facilitate and teach the rest of the team, and get things moving more quickly.
I'm about half dev and half UX in my skill set. I can train anybody to do some basic usability testing in an afternoon. But that person is going to miss some stuff that I see because I've been doing it for fifteen odd years and am bloody good at it. Ditto for user interviewing. Ditto for interaction design.
You get exactly the same thing on the dev side. Everybody should have some basics about operations, database design, system architecture, etc. But in any team more than two or three people you'll usually find some folk who are experts. They'll be the DBA gal or the devops guy.
That's doesn't mean having a DBA or a devops person requires the rest of the team suddenly forget about all their database/operations knowledge, or that the rest of the team shouldn't be involved in DBA/operations work. But having an expert around is useful. They can help you solve problems that you may not have come across before. They can help teach you new and better ways of doing things.
The great DBA and devops folk get the rest of the team up to speed with database/operations work as much as possible so they can focus on the really hard problems that are going to get in the way of the rest of the team's work.
That's what good UX folk do too (in my experience). They help get the whole team focused on thinking about users, and focus on helping solve the hard UX issues that are going to get in the team's way.
Prototypes and architectures divorced from working code are the kinds of thing that bog a project down and get in the way of people doing the real work, i.e. making the actual product.
No argument from me. No argument from most UX folk I know either :-)
I don't know what a "UX Designer" does, other than claim to do all the product thinking. In my experience, they mostly talk vaguely about how important they are.
Yup. Those people suck. As do some developers with "software architecture" type titles :-)
I know what you think you're saying, but read it over to yourself a few times. This is a tautology: you're saying that UX Designers are good because their responsibility is to do what UX Designers do.
And it's fundamentally wrong: the real party whose responsibility it is to make sure all that stuff happens is the product owner (entrepreneur in this case). The UX Design just has a job to do. The fact that it's a definable job isn't an argument that it should be someone's sole responsibility.
True
>The existence of a person who does nothing more than "UX" is a process smell.
Depends on what you call UX. My definition of the noun "UX designer":
1. Participates in Observational Research (Watches customers use your software) right along side the product owner and developers. Any one who makes software design decision should be apart of the regular feedback loop. This can even include sales people if they are making design and feature decisions. If this doesn't happen you build the wrong software wich is a really bad ROI. (Note if you are building software where you accurately represent the user, such as github.com, Then this research can be skipped.
1.b Mentors new hires (dev, po, qa, etc) on how to get the most out of most out of observation research. Answers questions with reasons based on facts and proven knowledge. It is the UX designers job to help everyone take his or her job. UX is the whole teams job.
2. Participate in research debriefing with the rest of the team.
2.b Mentor new hires, and all I said above. UX is the whole teams job.
3. Use the "scenarios", "personas" and "activities" distilled from the debriefing to create a story map with the whole team (Dev, Po, QA, etc). From this story map "User Stories" and tasks are created.
3.b Mentor... and so on as said above.
4. Guide developers and mentor developers interested in making wire proto types to usability test.
5. Participate in Usability testing of said wireframes workflows.
5.b you know the drill, same as above.
6. Debrief on the results of usability testing.
6.b same as above...
7. Iterate on wireframes if necessary.
7.b same as above... (whole team involved, UX designer is mentoring, her job is to teach the team to make her job unnecessary.
8. By now hopefully we have spent very little man hours in finding a great solution to our goal. So we can code. Developers code and UX designer pair designs with them.
9. Team usability tests the product they just created.
9.b Same as above, mentors, etc
10. Debrief on usability test
10.b ...
11. Iterate on design, pair design with devs. Getting small details like padding and animation speeds right. With the goal of teaching the devs to the point that they can take the UX designers job.
12. Usability test again
12.b ...
13. debrief 13.b ...
14. Team releases product if its working for users.
15. Surveys and observational research to find out how effective is the "out put" (what we built) at creating "outcome" & "impact" (user time savings, user delight, increase in sales, brand loyalty, etc).
17. Debriefing on the Observational research, surveys, and quantitative data. Looking for things we could have done better. What worked well, what didn't, etc.
17.b ...
Note: the teams goal is not to maximize "out put". Many teams don't realize this. The teams goal is to _Minimize_ "out put" and maximize "outcome" & "Impact".
For what it's worth, my experience matches timr's: if you get a developer and a designer to each read "The Design of Everyday Things" you'll get further and go faster than you would by adding a full time UX expert that can't design or code to the team.
In all the good startups I've known, everyone was responsible for sales, hiring and creating an awesome work environment. Does that mean that sales and HR people are similarly "process smells"?
After all, a solid UX from the start will make it far easier to build and find success than having to re-invent the wheel (your product) later on in the cycle just to save some time and money at the start.
My personal opinion, of course.
On a side note, the op is wrong when he writes "Bring in the UX designer before you’ve attempted any UI work." Yes you want to do UX first, but UI and UX are inseparable, because from the user perspective, the user interface(UI) always has a bearing on the user experience (UX). The UX should dictate the UI, but a good UX designer will always design the UI.
All startups work with constraints. For some startups design & UX are less important than for others.
Products CAN succeed with crap UX (though it can severely penalize the outcome).
Products CAN NOT succeed without _product_.
So if an entrepreneur has to pick between a rails developer and a front end dev, in some cases he has to pick the backend guy.
Rock, Entrepreneur, Hard Place
Which is indicative of the problem - UX is not just about the front end stuff it's about helping define what product to build.
Y'know all of that "Get out of the building" stuff that Steve Blank goes on about? The whole validating that you're actually really solving somebodies problem?
The UX world has a phrase for that. We call it "generative user research". We have a whole stack of useful toys in our toy box for helping folk do that well. We've already made, and learned from, the mistakes that I see folk in the lean startup world making.
I keep encountering companies that are just throwing money away building stuff too early, when a half dozen five minute conversations with some actual users would help them figure out what the right thing to build is.
The model of having the UX person in "control" sucks. They should be a peer team member not at the top of the hierarchy. But the value they bring is a lot more than just making-the-product-work-nicer. The real value, especially in early stage startups, is helping figure-out-what-product-to-build.
if i'm clear, you are saying, "the backend dev won't build the right thing if they don't don't a good UI person to guide WHAT to build".
Exactly ZERO startups that require _A_ backend to be built have succeeded with the right idea of what to build but no backend.
MORE THAN ZERO startups have succeeded by buildilng backends without consulting, often building the wrong thing first, or getting lucky, or with users that accept a SUBOPTIMAL (but better than status quo) experience.
In a perfect world you get infinite resources.
Obviously I'm painting this a clear either-or dichotomy, which its not, but the point is that sometimes, due to other constraints, an entrepreneur might have to make the call.
It doesn't make him a crappy entereprenur. Please understand that when you think "I won't work with him because he doesn't prioritize UX".
Absolutely. The thing I'd like to happen is for it to be an informed call. The stereotype I keep hitting about UX work is that:
* It's expensive
* It's more cost-effective to do it late than early
* It's just about making things "pretty" / "easy to use"
When in reality the opposite is often true. For example doing user interviews and user testing early is stupidly cheap if done right. It stops you wasting money by building the wrong thing.
Please understand that when you think "I won't work with him because he doesn't prioritize UX".
I do not and would not think that.
I do think that people who don't prioritise UX often (not always) don't understand the value that UX work can bring - and think that all UX work done by bringing in high-paid agencies / consultants that do all the work up front.
I'd try and educate them with examples of how it can help save them money in the very short term.
For example - a few months back I was talking to founder who was planning to spend about £20k to develop an "MVP" for this social recommendation site he was planning. We talked through a way he could test his idea with his real users for the cost of negotiating a poster placement at a local gig (free to very low 100s of pounds), thinking up a hash tag (free) and looking at twitter during a certain period of time (free). A five minute conversation saved that guy between 15.5 & 20k that he's going to be able to spend in useful ways to further develop the concept.
Another guy I talked to was doing his "get out the building stuff" and getting out to talk to users. He was getting great feedback and was planning to build. Five minute chat about interview style and it came up that he was, unintentionally, directing the interviews towards the solution in his problem space. Gave him some tips on non-directive questions and getting users to tell stories. Got a call two weeks later to say thank you and a nice bottle of booze in the post because - when he went out again and talked to users - he discovered some new and interesting differences in what folk were saying that radically changed what he was going to build.
(Note to self: find ways to get paid for five minute conversations in coffee shops, although the whisky was nice :-)
To pick a personal example we've got an in-house project aimed at the health/weight-loss for folk who "don't go to the gym". Coz I'm rubbish at following my own advice (and was in the target group so thought I was scratching my own itch) I started building our fantastic idea straight away - coz I had a couple of weeks free and, y'know, building shit is fun :-)
And yes - once we actually put it in front of users - nobody wanted it. We'd built the wrong thing. A couple of afternoons watching and listening and interviewing folk in that market told us what was wrong with the original idea, and has given us some great ideas for what we should be building instead (basically we were building something for folk with intrinsic motivation, we should have been building something for folk with extrinsic motivation). We wasted 14 days of work because I was too dumb to spend 1 day talking to people first.
I want UX skills understood and in the hands of everybody - because in my experience its the most effective way of building successful products cheaply.
Let's face it. As an entrepreneur, you have limited resources. There're only so many dollars in the bank account. These dollars have to be stretched to cover everything from pay and benefits to basics like coffee and internet access. Few entrepreneurs have room in their budget for deadweight, and a designer who proposes things that can't be implemented is deadweight of the worst sort.
Paul Rand
When, in fact, the positive ROI of usability improvement has been established for awhile: http://www.useit.com/alertbox/roi.html
A good UX guy will realize this and design to the situation, rather than preach some esoteric heuristics.
You have to take a look at your competition. If a high quality experience doesn't matter then yes don't do the 29 things. However, remember "Design and UX is the new IP" - Ron Conway
And remember Paul Graham has said "always run uphill". He meant that when he could solve either a regular problem or a hard problem at Viaweb he'd always solve the harder problem as if he found it hard, his competitors would find it almost impossible.
So you can use UX and Design as your "barrier to entry"/"hard problem" amongst your competition. If you are solving some other non UX hard problem, then have a mediocre user experience if it makes sense.
4. A designer who sweats every detail is a designer that never finishes. Sometimes the designer just has to let loose those details that only that designer realizes are a potential issue in the design, not functionality. If during review enough comment on it then fix it, otherwise let it go.
10. I cannot agree with this more. Although I'm a front-end developer so I may be biased just a tad bit.
14. I don't necessarily agree with this. It depends on the project and established goals. As someone else pointed out, if you do this you may give the desktop user a less than ideal experience. If you're willing to put some of that cut stuff back in for the desktop people at some point then sure. But to give a mobile experience to desktop people cannot be a good thing.
15. Almost contradicts rule #4. Some people would say sweating the details is close to over design.
26. This is excellent advice. The hard part is knowing the difference between an app with a good design versus bad. This is a hugely subjective thing. Popular apps don't necessarily have good UI. Also, be careful, because in today's environment if you get an idea from an app you may get sued for it.
29. Not necessarily true. Depends on the people. Your best bud may refuse to document his code in a useful way (or he may just suck at it) and the best coder in your group may be a total jerk outside the professional environment.
I'm a glass half empty kind of guy so that's the focus of my comments. The rest can be assumed I agree with or neutral on.
Also, I kept getting confused over which designer he means as he explains his points. There are three examples in the article; Visual, UX, and UI. But then he just uses "designer" too often for all three.
This introduces an annoying 'waterfall' process where I can't test whether the designer's ideas actually work in-browser and practice until they're officially 'done'.
CN to managers: don't make a designer your product todo list. use a system for that and accept some quirks and broken-ness at first.
Read quora's photoshop-less design process for an alternative (and arguably better) approach: http://www.quora.com/Joel-Lewenstein/Joels-Posts/Life-Withou...
Bring in the UX designer before you’ve attempted any UI work. I can’t tell you how many times my clients have said “I wish I’d brought you in earlier!” The UI changes are often enough to necessitate technical re-architecture. Starting with a good designer from day one will save you a lot of headaches later on...
If they nailed it on their own, they're not going to bring someone in, but still.
Anyway, to play the devil's advocate in this situation, I believe the gist was more along the lines of "please involve UX designers early on in the process, and know that we're not just your make-up appliers."
If that involves showering him with money, then sure.
>> "29. Please, please, please spend time hanging out in the latest and greatest apps, regardless of their personal relevance or interest to you. If you do, your expectations of a “good experience” will be raised. Archaic team communication tools are often a good indication of what the decision makers believe qualifies as “good.” (Hint: it’s often a very low bar relative to what’s possible!)"
I can't emphasize enough how important it is to use well designed tools, they will influence your product.
>> 14. Design for mobile first (even if a mobile app is not in your roadmap). The constraints of a mobile context will force you to focus on what’s essential, and help you cut what’s not needed. The question “How would I design this as a mobile app?” always clears my head and helps me find the simpler, elegant solution.
Unless you are primarily designing a mobile app, this ends up shortchanging the web user. A full web interface can always do more and the challenge should be converting those features to mobile as opposed to dumbing down the design for the lowest denominator.
http://www.abookapart.com/products/mobile-first
It's a good (and quick) read, even if you don't agree with it, as are all of the A Book Apart publications.
>A full web interface can always do more and the challenge should be converting those features to mobile as opposed to dumbing down the design for the lowest denominator.
I think that this sentence gets to the crux of his point. Terms like 'dumbing down' and 'lowest common denominator' to describe the mobile experience seem a little loaded to me, and imho, this is exactly the type of situation where deving movile first could provide surprising insight into your MVP. I'm talking honest to goodness slap in the face reveals.
I think it's safe to say we have different opinions on this point, but man...I simply can't count the number of "Hey check out my startup" websites that I've clicked on and just kind of had my jaw drop at what was going on. I'd honestly say the majority of the ones I've seen could have benefited from this approach. That's completely anecdotal, I know, but it's the impression I have.
Dropdown menus - Mobile first almost always means multiple clicks to get to the same place, which is more annoying on a slower browser.
Commenting system - still yet to see a decent one that I would one on a mobile interface
Flash/animations - like it or not, moving images grabs attention but does not translate well to mobile.
Page width - 1440 pixels on my shiny screen, but text is stuck in a 200px box that forces me to scroll down. Flexible width usually gets thrown out when you add sidebars and ads.
Large Buttons - Great for mobile but I'd rather see context that a sign up button taking half the page
Related content links - Especially for blogs/news websites.
Inline images - My primary annoyance with this article which is ALL TEXT. Mobile design says dont take up an entire screen view with an image. Web first design says even if the current text is boring, people will scroll down if they see an interesting image.
I honestly believe that having separate approaches will allow for better UX, time and cost permitting.
Ah, but you aren't throwing them out. You're using a constrained UI to identify your MVP, then adding those very features in to the full web site where it makes sense. We're looking at the exact same behavior and using almost opposite language to describe it :)
>I honestly believe that having separate approaches will allow for better UX, time and cost permitting.
Fair enough.
>Commenting system - still yet to see a decent one that I would one on a mobile interface
On a side note, I passionately agree with this. I think there is a tremendous opportunity out there for anybody that can solve this problem elegantly. Group communication is a fundamental human behavior, and so much of it is happening via our mobile devices. There's a much better mousetrap to be built here.
>> "15. Don’t over design. Less is better in the early stages. Launch with too much going on and you won’t know which pieces are broken and which are working."
That's my favorite. I feel like I always see new products trying to hard on their first few product design rounds. In my experience, it's a great thing if you start small (with fast iterations) and fail X times rather than spending 5 years on a single attempt, that still fails miserable. Testing product design at a quantum level goes such a long way in the long haul. That goes with A/B testing as well.
What, there's a "UX designer" AND a "visual designer?"
I do both. They're completely connected. How could you do "design" and not include the user experience?
Sounds like another one of those things where people "specialize" in certain areas but really don't have a clue what they're doing, and charge a hefty price tag for a whole lot of nothin'.
And it's worth nothing the design of that blog makes me sick to my stomach.
Do you feel that while UX is at one end of the spectrum, visual designers at the other - UI Designers sit squarely in between them?
I ask cause I love visual design, making elements pleasant to look at, enticing user to push buttons or guide their eye to areas I want them to look at. But I also spend huge amounts of time time thinking about user flows, scenarios and tasks, how one page flows to another, how it all connects and constantly going around asking/testing with people if the flow is confusing or interfaces aren't clear on what they should do.
I guess UI Designers are half UX and half Visual?
There is UX that 'feels' amazing but is used in an insubstantial product (aesthetic UX) just as there is functional visual design—think of the IKEA catalog which emphasizes visual simplicity as a means to sell, in addition to the 3D rendered scenes used to save in production cost.
"You get what you pay for. I charge a lot. But, I guarantee you’ll save money in the long run. Most visual designers at 1/4 my rate will take much longer and still not get you where a seasoned veteran will. Note: veteran doesn’t necessarily mean years experience—2 years at a dot com startup taught me more than most people learn in 5–7 years at a big company."
“good designers start with the data“
Only when you deeply understand the structure of information can you present that information in a meaningful way. In other words, a good designer turns data into knowledge. And to my mind, the key point of good software design is starting with good data structures. In general, the model shouldn’t need to change—a changing model is an ill-defined domain. Once you understand the domain well enough, features are just algorithms.
I think I agree with you, but I'd probably phrase it rather differently. To me, data is already knowledge, but often we are limited by having too much raw, low-level knowedge and not knowing what to do with it.
A good UX can help us to understand the data and/or to make actionable decisions based on it, and so to me, a good designer (in the sense we're talking about) is someone who helps to build such a UX.
This feels a bit like if a programmer went round and said 'everybody uses node.js these days, are you getting a programmer who uses PHP or Node.js' completely ignoring the fact that the proportion of php to node code written is like 99.999 : 0.001.
Most of the designs I see still give little thought to the UX of the entire experience.
He even mentions it himself without realising the irony:
I spend a lot of my time just getting everyone on the team—designers included—to see the problem in a different way, not the way it has been implemented).
http://ianstormtaylor.com/design-tip-never-use-black/
EDIT
It looks awful in Chrome(Windows) but in Explorer it's OK...
:)
This page fails that contrast guideline algorithm (258 out of a minimum suggested 500) and is a little annoying to read even for someone without a sight/color deficit.
(Clicks the obvious "Let me explain" button.)
Ah, and he's currently available for consulting too? I'm shocked, shocked I say!
Something notably missing throughout his entire site is any evidence of results. Or past clients. Or having ever produced or contributed anything of value at all, really.
Which is ironic for a UX designer, because if I were looking to bring in some more help for one of my companies, the first thing I'd want to know is what benefit that person is actually going to bring.
Let's just go back "web designer." Please.
You can also have one person doing all of them, the same way you can have a single engineer at your company, but very very very few people can do all three well, and on many projects there is too much work for any one person to do.
Also, much of UX design doesn't necessariy fall under the category of web design. A UX designer is looking at the entire product experience, which would potentially include things advertising, customer service, advertising, etc.
You can use the shorthand "designer"... that's fine. But you can't just wish away entire professions. There are pairs of Graphic and Experience Designers who have almost nothing in common in terms of responsibilities and skills.
"Typography exists to honor content."
This is very important. On the flip side, I have seen too many designer profiles online where they don't clearly identify whether they are UX designer or visual designer.
As a long time designer turned developer, supported. I would have made the tone a little less preachy (and added a dash of "relatively speaking"), but hey, I didn't write it.
Also i hate it when they say: Programmers cannot do UX. They are too technical. Well i do it all myself. I dont call myself an UXer. Because its just a small part of creating a product.
"What works is better than what looks good. The looks good can change, but what works, works."
Again, I'm no expert and I'm just a technical nerd who "doesn't get" designers. Probably should keep my mouth shut, in retrospect ;)
It's the design equivalent of asking for a developer who is an expert in front-end, back-end, databases, operations, scaling, etc. etc.
pay attention to ux!