Jordan Dobson inspires us to never stop learning and be generous in sharing knowledge with others. He encourages us to craft prototypes in order to gain valuable insight early and often. He challenges designers to gain empathy for their developers by learning a bit about code. He also shows us how the little details can make a big difference.
Jordan Dobson (Minutia) is a hybrid designer, developer and prototyping visionary with over 17 years of experience. He brings motion into visual, product & UI design to build amazing digital products. He’s a freelancer currently contracting at Skype. He’s worked at Microsoft and is also co-founder of the Seattle FramerJS Meetup. Back in the day he could ollie off a launch ramp clearing four trash cans & land it.
- Secret Identity/Origin Story (2:16/5:18)
- Biggest Superhero (13:44)
- Second Career Choice (14:43)
- Biggest Failure (16:47)
- Awkward Testing Story (22:12)
- Design Superpower (25:22)
- Design Kryptonite (28:52)
- Design Superhero Name (33:48)
- Fight For Users (35:07)
- Future Of UX Design (37:21)
- Habit Of Success (39:50)
- Coder Who Designs Or Designer Who Codes (42:34)
- Should Designers (43:01)
- Best Path To code (51:18)
- Invincible Resource (54:28)
- Book Recommendation (56:52)
- Best Advice (58:29)
- Listener Question (1:00:17)
- Most Excited About (1:04:06)
- Contact Info (1:06:33)
[RESOURCE] Little Big Details
[BOOK] Grid Systems in Graphic Design
[BOOK] On Web Typography
[BOOK] Defensive Design for the Web
[BOOK] The Lean Startup
[BOOK] Don’t Make Me Think
USE YOUR SUPERPOWER OF SUPPORT
Here’s your chance to use your superpower of support. Don’t rely on telepathy alone! If you’re enjoying the show, would you take two minutes and leave a rating and review on Apple Podcasts? I’d also be willing to remove my cloak of invisibility from your inbox if you’d subscribe to the newsletter for superguest announcements and more, occasionally.
AWKWARD TESTING STORY
Nothing too crazy. While I was working on the Sway product for Microsoft I was the only person working on the prototype, so I designed it and build it, and I had not been a part of those types of user testing scenarios often at all. Just being in a start up is usually like, “here’s a budget we need to ship in four months and we have no time to test.
So I was definitely interested in sitting and watching these. Since I built it and designed it (it was hosted on my local server on my machine while I’m watching) and it was fun to be able to watch people do this testing. They’d hit these little speed-bumps that I never even expected that totally would distract from what we really wanted to test and I was able to jump in and fix those things or address those things on the fly in between the user testing appointment. It was pretty cool because it helps us focus on the test we are actually trying to run, instead of those little issues that were preventing people from getting there. Sometimes it would just be like a scrolling thing, or the button wasn’t as big as it needed to be, so they were just missing it. Then they would go on a tangent about why they hate when buttons are small on these 14 sites and get off track. Then you’re like “No! there’s so much more for you to see! don’t focus on this.”
Honestly I haven’t been a part of too many user tests myself. Most of mine have all been friends and family. I did a little bit of guerilla testing taking phone prototypes and giving them to people in line at lunch and a lot of people are too interested in that.
I think it would be along the lines of being able to focus on smaller details while still seeing the big picture. Whether that’s interaction motion typography or just design patterns in general, or copywriting because those little details add up to to define the project as a whole.
Being able to break down complex problems into simple, solvable chunks would be another one. I feel like I’ve been apart of so many projects that I can see so many different ways to break things down.
It’s having too much time on a task, because I will start to just get in this absorption mode where I don’t necessarily do too much. I tend to like the pressure of time to help me make decisions.
Also not enough team feedback. I’ve always brought in people that help me progress quickly because I can get a little randomized at times. I get a bit too curious and self serving in my work and then I end up pulling all-nighters to catch up.
HOW DO YOU FIGHT FOR YOUR USERS?
For me, I’ve had my fair share of struggles with engineers and developers, so I’ve taken it upon myself to learn languages and help enable our team to see through the details you want to see in our projects. And I want to work to simplify the process that the user has to go through, to make sure they have to do less to get on with their task. It reminds me a lot of the Defensive Design for the Web a book by 37 signals. They were huge influences of mine, I pretty much read everything that they wrote back when I started using Basecamp in 2005 or so. The book’s really great. It’s kind of along the lines of the Don’t Make Me Think. They would dive into a flow for booking a flight and just point out all of the little gotchas that are in there. I think that’s why I really love prototyping and designing and getting through the interactions early, because they help expose more of the little issues that you don’t expect early on, before they come up towards the ends of the project when you’re trying to ship something and you have to put in little fixes or crutches to help you ship on time.
FUTURE OF UX
I think it’s a lot less of looking at a terminal, like a phone or a computer and having this processing device that acts more like a slave with secondary things taking the place of what your phone or computer might do. VR, augmented reality along with voice commands. What exciting right now is there so many of those new things coming up.
HABIT OF SUCCESS
I think it’s definitely exploring ideas, using things like Framer, to take a concept and explore it and push every angle I can on it to really hone in on what’s a great experience. And then, testing in front of people and proving myself wrong, or destroying all these assumptions I had. And then, taking that information that I learned, and use that to teach and explain, which helps me become a better programmer too. All the stuff that I internalize, I then have to explain to someone else build up a ton of metaphors to designers.
Also, what do they say? “A prototype is worth a thousand meetings.” This gives the ability to take an idea and explain the concepts to others and get buyoff quickly.
Practice a lot and teach. You can’t always get the projects you want, so you have to find projects you love doing.
Also, define what the problem is and solve it; exercise that muscle. By teaching you force yourself to project your understanding outwards to others. That helps you understand it better as well.