Things I, as a designer, wish more tech startups knew(the-pastry-box-project.net)
the-pastry-box-project.net
Things I, as a designer, wish more tech startups knew
http://the-pastry-box-project.net/stephen-anderson/2012-september-7/
28 comments
One thing I, as an entrepreneur, wish more designers knew: I can't do everything, and I have to make tradeoffs based on cost-benefit analyses, and you will influence me more if you speak in that language. All but one of these 29 things (in fact, there are 32) are additional things this guy thinks I should spend my limited resources on.
All too often, UI people end up being marginalized because management doesn't support them. Unless you just want "a new coat of paint" a good UX design will require some hard changes and product realignments. If the CEO is not interested in taking part in that conversation then you'll never be able to build a good product.
Actually... most often UI people end up marginalized because they think their ideas and their needs are more important than they really are. Designers are, in general, their own worst enemies.
Interesting statement- any more concrete examples?
"Never build a good product" is too strong. We as hackers have quite a few exceptionally powerful tools with terrible UIs (e.g., emacs) and it only really hinders the earliest portion of one's career before climbing the learning curve. Consumer stuff has a tendency to over-optimize for approachability, which my get you eyeballs but not dedicated power users whose lives revolve around tools.
It depends....
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.
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.
All too often, "UX Designers" end up marginalized because they're wankers - people who don't code and don't design, but want to get right in the middle of things and fling around opinions. Especially dangerous are the representatives of this breed who want to "manage process" as a way of "designing the product". Hiring that kind of person is a great way to get a useless bureaucrat on your team.
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.
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.
Yes, and terrible engineers can also completely ruin the process. As can a terrible manager. What's your point?
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.
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.
If a UX designer produces mocks and designs, they're a designer. If they produce software prototypes, that's called an engineer.
My point is that "UX Designer" is a largely unnecessary job description that is filled by quality execution in more traditional roles.
My point is that "UX Designer" is a largely unnecessary job description that is filled by quality execution in more traditional roles.
Sadly, "designer" is a poorly-qualified term. When I hear someone say that it's hard to tell whether they mean a graphic designer or a UI/UX designer (or possibly even a product manager or something).
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.
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.
"Or perhaps you mean _product design_, which involves a terrifying gestalt of UI/UX design..."
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.
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.
Are you arguing that there is no difference between UI designers and graphic designers? It may all seems like "silly design stuff" but I promise you -- there's a big difference between the two. For example, UI designers usually need to be able to code (if perhaps only rudimentarily).
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).
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).
Maybe you meant something more specific, but you seem to be implicating yourself. Here's what you said above:
"If a UX designer produces mocks and designs, they're a designer. If they produce software prototypes, that's called an engineer."
"If a UX designer produces mocks and designs, they're a designer. If they produce software prototypes, that's called an engineer."
[deleted]
The problem is that "designer" can mean very many different things to different people. There's a large chunk of the world that always read "designer" as "graphic designer". Mixed up with this is the problem that the various communities of practice are, I think, searching for a more common identity.
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.
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.
I'm a UX designer and I do both code and design.
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.
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.
[deleted]
Clearly, you've had interactions with fakers who call themselves "UX Designers".
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.
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.
This stuff sounds like a complete antipattern to me. Who shouldn't be thinking about users? That's not a specialty.
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.
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.
This stuff sounds like a complete antipattern to me. Who shouldn't be thinking about users? That's not a specialty.
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 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 :-)
> it's [Real UX Designers'] 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.
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.
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.
>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.
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"?
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"?
So true, so well said. Could not have said it better.
>Everyone on the team is responsible for good user experience.
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".
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".
I think you just made timr's whole point. You could have just said "the UX guy runs the observational research and supervises wireframing and usability testing" but that just doesn't sound like a FTE.
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.
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.
Yes! Totally agree! There should never be a person whose sole job is "UX". I've encountered many of these people and have never seen one add value to a project.
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!)
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!)
Well - there's a lot more to IA than wireframes :-) Lou Rosenfeld's book "Information Architecture for the World Wide Web" is still a nice, small read if a little dated now and more oriented to content-based sites.
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.
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 good UX designer doesn't linger around after doing the job. Their utility drops drastically after the initial design. If they do have to stay, then they haven't done a good job of communicating the key points and observations.
A good UX designer SHOULD stick around because their utility after the initial design is to conduct usability tests, user research, and user feedback to make sure initial design decisions were sound and that the experience that actual users and customers have align with the goals of the business/organization (ie - conversion rates, profitability, ease of navigation, etc).
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.
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.
"stick around ... to conduct usability tests, user research, and user feedback" is exactly the pitfall that UX falls into when it fails. We've seen it happen so many times, and en masse. This process-driven design fails, because it tries to put the designer in the middle of development, while taking away the responsibility for good design. It is attractive, because the UX designer can blame the users' "unexpected" behavior. It is attractive, because it exchanges the experience, with experiment. If the design is incomplete, it is incomplete, period. If the users have to be observed, let it be done, the development can wait. There is nothing worse than a designer who makes blind guesses about the design hoping that some miracle during the "usability test" will reveal a beautiful solution.
I don't care who does it - but doing usability testing, user research and user feedback isn't failure. It's validation. It's testing. It's closing the feedback loop.
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?
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?
It does matter who does it, when it is done, and how the results are used.
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.).
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.).
Ten years ago I thought this way. Now I don't.
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 :-)
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 :-)
Adrian, I finally watched your talk. Thank you for the link. It was a good talk. (Note to self: keep a few 40 minute talks handy in case the next discussion goes into a general area of interest :-)
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.
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.
I've learned not to work with entrepreneurs who do not understand the value of design and user experience.
There are plenty of entrepreneurs who understand the value of ux/ui. My job is to design an a app that is not a pain to use, not explain cost-benefit of this.
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.
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.
Its not a question of understanding that those have value. the original post is just saying that there are more things that require attention than he can address.
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
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
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.
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.
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.
yes, i understand what you are saying.
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".
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".
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.
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.
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.
I've learned the value of not working with designers who do not understand the realities and constraints of entrepreneurship.
What is the value of not working with a designer whose recommendations can't be implemented due to your constraints? Did they pester you daily about their recommendations?
Worse. They asked for money.
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.
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.
“…I will solve your problem for you and you will pay me. You don’t have to use the solution.”
Paul Rand
Paul Rand
That sucks. But the problem there is exactly the same as developers who propose solutions that cannot be implemented within the budget. It's bad developers/designers - not bad development/design.
As Nielsen said, the ultimate goal of usability is cash. Unfortunately, this article comes off more as a designer rant, as if startups should invest in usability just because it somehow makes the world a better place.
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.
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.
While I agree with you, I think you have to approach these 29 things as a helping hand for when you're deciding to use those limited resources.
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.
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.
"Designing for quality will always be more expensive. It's not about expense. It's about the return on the investment." -Jared Spool
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.
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.
You need to be convinced that a designer is needed in order to pay for it, and you may not need one: If you trust that your product is designed not according to the convenience of the underlying technology (and the computation device) but to match the goals of the [put your target audience here] #1 user Jane (age 21, last year in college, started thinking about her finances, has classes all day, needs to straighten up GPA before graduation, good at math and office software, shares apartment with 2 other people, uses to phone for IM and instagram), and #2 user Hillary (age 58, manager in a paper company, both kids graduated from college, has meetings throughout the week, 5 weeks vacation, heavily depends on her phone for calendar and email).
Agreed, I think lot fo the stuff here, it's his job to educate others about it.
Maybe he should write a blog post about it and put it on HN.
3. So a designer who uses lorem ipsum is not a designer? What? So if he's hired to work on a project he sits around waiting for copy before comping design ideas? As someone who's been in this position it is quite wonderful to start with finished or semi-finished copy but that doesn't always happen.
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.
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.
totally annoyed with his #3 as well. Been working with a folks who want everything to be decided by the "designer" first and make copy-perfect photoshop templates first - even if they're not that happy with the design.
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...
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...
While I think a lot of this is good, did anyone else get the feeling the _real_ gist of it was: "shower me with $$$"?
Yes, it was 'definitely' a sell sheet, but most of the points were good and have merit.
Agreed. A lot of the points seem to be stressed from the point of explaining how important what he does is.
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.
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.
I did get that feeling, but i would not have cared as much if he would have shown some awesome before and afters or some real-world examples.
To be fair, aren't most blog posts about that? ;)
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.
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.
I totally agree with your devils' advocacy. The problem occurs when the people making decisions are not able to differentiate the UI(can be changed anytime) from the UX.
I was quite surprised not to find a "I'm available, hire me!" tagline at the bottom, great points but I kept getting distracted from them.
Some great points here.
>> "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.
>> "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.
Good points, but I dont agree with this:
>> 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.
>> 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.
If you agree with point 27 (questing for Minimum Viable Product/Experience), then rule 14 makes a lot of sense to me. He isn't saying not to design a full web interface (which as you point out, can do more). He is merely saying by doing mobile dev first, you are essentially forced into discovering your MVP more lucidly. You can then add features to the full web interface from there.
>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.
>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.
I agree with MVP and your anecdotes - less bloat, all the better, but from a UI/UX perspective, let me give you a few examples of what usually gets thrown out in a mobile first design:
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.
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.
>let me give you a few examples of what usually gets thrown out in a mobile first design:
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.
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.
Here is a solid book about mobile first development:
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.
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.
It's not dumbing down, it's simplifying. By designing mobile first, you force yourself to think about the priorities in your UX. You can still add all kind of things on top in the full web interface, but that's on top of the core experience.
Around three years ago I postulated that websites will soon start to develop their mobile version first and not second. Little by little I keet seeing more examples and the last year it has really been accelerating. It is an interesting time and while many besides yourself will find offense with this "rule" I would expect more of it in the future.
That one bothered me too. For someone so focused on the experience, it seems narrow to think of focusing on one platform that admittedly, might not even be used. Shouldn't you be focused on building the best experience on the intended platform?
One of the best UX/UI designer articles I've seen!
>> "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.
>> "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.
This is absolutely ridiculous.
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.
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.
If the visual design is like Google or many other web apps, then it's possible that a UX designer can set you on the right path. If you want a very pretty, original look, that could require the services of a visual (graphic) designer.
Been lurking here for months but I made a profile just to say Thank God. Thank God someone else gets it.
Question for other designers:
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?
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?
To paraphrase from Yves Behar, "there are two kinds of designers. Good ones and bad ones. Good ones can do all kinds of designs. Bad ones invent new subsets of design to excuse their failings."
To me, the spectrum ranges from Functionality to Aesthetic; each type of design can be approached from a more functional or more aesthetic approach.
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.
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.
Personally I don't like the "UX designer" job title, but would put UI Design and Visual Design under the umbrella of UX (ala JJG's classic "elements of UX" diagram http://www.jjg.net/elements/pdf/elements.pdf)
After this section below I stopped reading. He probably is a good UXer. But also an arrogant one. The best ones understand that they always need to learn.
"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."
"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."
This really stood out to me:
“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.
“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.
In other words, a good designer turns data into knowledge.
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.
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.
How about this: good design lets you see the forest in spite of the trees.
The first bit seems very much "Hire a UX guy, not a graphic designer" but it does got better. Still, the "sell, sell, sell" feeling of the piece leaves me cold.
Yes, and it's still fairly revolutionary for a designer to even think of UX or usability, contrary to what the article claims.
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).
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).
I guess effectively using contrast isn't one of them...
Came here to post this. For some reason a blog post about design or UX posted to HN (by a design / UX guy no less!) has at least one failing in the user interface department that can be spotted by a $0.02 programmer.
Yeah, he embraced the idea to never use black:
http://ianstormtaylor.com/design-tip-never-use-black/
EDIT
It looks awful in Chrome(Windows) but in Explorer it's OK...
http://imgur.com/a/CA7Ow
http://ianstormtaylor.com/design-tip-never-use-black/
EDIT
It looks awful in Chrome(Windows) but in Explorer it's OK...
http://imgur.com/a/CA7Ow
Looks like he embraced and extended it. Not using #000 is one thing, having almost no contrast is another.
Hello. Just to make things clear. I made the design. I run the Pastry Box Project. Stephen Anderson is a guest.
:)
:)
In the vein of constructive criticism: there is a set of W3C-suggested accessibility guidelines that include tests for things like the contrast between text and its background (http://www.w3.org/TR/AERT#color-contrast).
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.
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.
Thanks a lot. Constructive criticism is always appreciated. A redesign is on its way. This issue will definitely be taken into account.
It's not his design. The Pastry Box Project is a collaborative blog made by someone else. He just contributed the content.
Oh, great. Thanks for the info. This is his web site:
http://poetpainter.com/
http://poetpainter.com/
Ah, I see. He's a thinker, a consultant, and a speaker. Who would have thought?
(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.
(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.
I am so sick of job titles like "UX designer," "UI designer," and "visual designer." All visual design on the web is related to UI/UX. You can't do UI design without affecting UX and vice-versa.
Let's just go back "web designer." Please.
Let's just go back "web designer." Please.
You can put Graphic, UI, and UX all under the umbrella of "Design" if you like. They are specialties in the way that front-end, back-end, or database engineering are all specialties.
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.
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.
Jakob Nielsen would disagree with you.
Starting with the data is sage advice. Reminds me of a Robert Bringhurst quote that smacked me in the face when I read it:
"Typography exists to honor content."
"Typography exists to honor content."
"1. Learn the difference between a UX Designer and a Visual Designer. They are not the same. And while there is (and should be) a lot of overlap in skills—it’s good to know what the designer you’re hiring thinks is priority."
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.
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.
Minimal Viable Experience is what I took away. I think it serves better than MVP in the early days of the product.
I really like the general theme of pointing the designer into the core of the startup, and think a lot of this is very good, accurate advice.
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.
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.
The color scheme on that page is so washed out that my eyes did a double take. That's one thing I wish a designer knew about users - not everyone is using a crisp iMac to view a website. I'm on my already washed out PC and their color scheme makes it even worse.
Yeah, I'm starting to come to the conclusion that modern design == hard to read websites. Incidentally, they are also usually slow.
I agree that UX design is important. But it is basically applying common sense. See common solutions to UI problems and apply them. Actually its the fun part of creating an application.
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.
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.
Design isn't just "Front End" or "Interface"; Design is everything -- most importantly functionality, process, and model.
"What works is better than what looks good. The looks good can change, but what works, works."
"What works is better than what looks good. The looks good can change, but what works, works."
I'm no expert, but wouldn't a startup want a designer who wasn't so picky? Instead wanting a "full stack" designer; who could solve all their visual worries?
Can you define full stack designer?
I just made it up, but I guess it would be a designer that can do the whole song and dance. In the article he specifically mentioned that UX and Visual Design is not the same thing; fair enough but startups want to do more with less...
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 ;)
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 ;)
In the design world these are known as "unicorn designers" - since you're about as likely to find one :-)
It's the design equivalent of asking for a developer who is an expert in front-end, back-end, databases, operations, scaling, etc. etc.
It's the design equivalent of asking for a developer who is an expert in front-end, back-end, databases, operations, scaling, etc. etc.
Nice! Knew what a fullstack programner was so I was thinking it might be along those lines.
As was mentioned before, more often than not, startups have limited funding and can't afford both a UX guy and designer. Full stack for the budget! FTB?
I'd prefer "relevant stack designer." Full stack implies backend and database, about which the designer really need only have a basic understanding of constraints. Relevant stack would mean a mastery of front-end technologies.
I suppose it can be definite as "someone who does what is asked for with nice(maybe not spectacular but at least nice) results, whether it's his main field or not, as long as it's related to it."
This is some really great advice, 'The best UIs often start as written conversations between the user and the system.'
30. pick a domain that people actually remember. 3 hyphens on a .net wtf, bro?
Very good writeup.
the tl;dr;
pay attention to ux!
pay attention to ux!