Grades and individual feedback on Blackboard.
Key learning from this module
Prototyping = modeling possible design choices for a client + justifying those choices via appropriate verbal or written communication + making a possible future for a digital product or service visible to a client
What you’ve experienced in this class is but one leg of the UX journey
As hard as this may be to believe, this class has pretty much been modeled on one design sprint. A design sprint is usually a 2-week process for building (or rebuilding) one or more elements of a digital product or service.
So, yes: UXers in industry accomplish everything we’ve accomplished in this class in 2 weeks (or less).
And yes, I’ve done a design sprint or two like that. They are NOT FUN.
I mention this not to undercut any of the great work you’ve done in this class (you really have, seriously!), but to give you a picture of your possible future life as a UX designer in industry, should you choose that route.
That being said, the median salary for these jobs is about $75K a year, so they are definitely good jobs to have!
Please feel free to add anything you’ve done in this class to your portfolio
The way to build a UX portfolio is to save deliverables from projects (prototypes, usability testing scripts, content audits, etc.). You always need permission from clients to share these. I’m giving you permission to add anything from this class to your portfolio.
For the future professors in the course: if you want to write about some of the stuff you’ve done in this class, that’s also possible, but please talk to me first. There are certain things you won’t be able to write about, but there is much you could write about.
I look forward to seeing your final projects where you tie everything together!
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.
UX Prototyping: Choosing the Right Tool for the Task
I’m going to be the annoying pedagogy person for just a second (sorry):
So it strikes me that a lot of what we have been learning is directly applicable to many of the goals that I focus on when I teach composition (I’m thinking “writing for publics” here but there are other approaches) however, we never frame things in UX terms.
Would anyone have any framing and/or focus suggestions for concepts that might be most useful to undergrads looking to enter the workforce?