Grades on Blackboard.
Prototypes are often treated like “the answer” to UX problems
So, in my humble opinion, there is a bias towards prototyping too early in a lot of the rank-and-file UX design community, AKA the people doing the majority of the work. These folks work insanely hard and are often put in very untenable positions: they have to do “design sprints” that are often as short as two weeks in length and that are supposed to produce high-fidelity prototypes.
Essentially, UX in a lot of organizations looks like this:
- Backend Developer: Does the heavy-lifting of programming an applications basic interactions
- Frontend Developer: Does the heavy-lifting of designing a program’s interface
- Graphic Designer: Makes non-programmable elements like logos, fonts, icons, etc.
- Additional Developer or Designer who says they know about UX, but who is really just good at prototyping
Of course, at this point in the process of this class, I hope you can see the problem with this arrangement. Just because someone can make something that looks really nice, and convinces other developers it solves problems, doesn’t mean it’s the best thing for users. In fact: often the thing that looks the best to developers is the worst thing for users.
User insights really are the answer
The fact that prototypes are often used to stand in for interactions with real, live users is symptomatic of the current state of web applications. There’s a reason why 97% of websites fail at usability. If everyone was talking to a UX person, consulting with them, etc., that number would be a lot lower.
Here are some of the excuses I’ve heard from real, live people working as UX designers working in major, fortune 500 companies:
- “I don’t have time to do usability testing.”
- “I have a boss, just like everyone else, and they have a bottom line.”
- “We usually come up with a prototype the day before we have to launch it, so I literally have one afternoon to interact with users before the meeting.”
This is not to beat up on these folks. They are not the problem. They are part of the problem, certainly, but they are really not the problem.
The executives of companies are the problem. When you have a guaranteed audience of 50,000 users, it’s hard to justify conducting time-consuming, expensive usability testing and user research. This is at the heart of the UX conundrum: in order to solve UX problems the right way, you have to invest money and time, and you have to engage in activities not typically valued by corporate culture: qualitative research, research that doesn’t immediately create an ROI (although the cost of not having a good UX is estimated to be very high), product design that is a remove away from what the final product will look like, etc.
It’s understandable, given this culture, that solid UX research often gets short shrift. This also doesn’t mean that graphic designers and web developers can be effective at UX, however. It doesn’t mean none of them can. It means UX is a skill set all its own and needs to be treated as such.