Cool site. Very Apple-y in the downloads area.

For remote Zoom is by far the best tool I've encountered.

You can share your screen AND mouse control to give the user access to the thing you'd like to test (while it still being secure)... and you can record which is the best way. Additionally because the interviewee has screen share you can easily ask them to 'show' you what they mean or their process and collect precious secondary artifacts.

Then after the fact Zoom's transcription service helps you search some of the results. We do this where I work where you can search key words in research and it brings up a bunch of sources and links.

Zoom of course won't recruit participants for you. So if you need that then you're out of luck (imo I prefer to build relationships with the people testing for longer term ethnographic stuff).

I don't work at Google so I don't know.

Liked the article. Some interesting thoughts — and I like that it questions some of the principles of usable design.

One thing I found off though: If the old principles might not apply why use ever flattening logos as an example? Kind of counteracts each other.

I also don’t believe the simplification of an interface of a design for clarity can be conflated with infantilisation. It’s the same process sure but I see them being for different ends or means.

Overall though I do find many modern images in design have gotten a bit sterile. One interface I saw recently had disembodied 3D hands that looked like fat baby hands floating around. So many illustrations use human forms w weird colours to signal ethnic diversity (why not use just use black, white and brown skin tone?)

Interesting thoughts here though for sure. Enjoyed the read.

Pushing AirTable data to a web wrapper front-end and packaging it on the app store is not what I would define as a "real" app. I would categorize this as a way to create very realistic test prototypes (which in and of itself isn't without merit).

I would argue Dribbble is a much better and thriving community because it's about people actually making things. UX researchers and product people tend to throw a ton of shade at it, but in order to post you gotta throw up a shot.

Not so with other aspects of design. So generally the discussion tracts towards a bunch of arguing product designers or self promotion. None of which are that compelling.

The solution, of course, is to post useful or interesting professional topics and share articles that are legit interesting but no one does that. So here we are.

The other "DESIGN NEWS" reddit died a stillbirth for this reason too.

I’ve used this type of test, as well as a competitive benchmark user test and both are EXTREMELY helpful. Lots of people assume because a competitor does something then they should too. But there are two problems 1) who knows if your competition knows what they’re doing. Their users could be suffering and 2) even if your competition does know, you probably want to figure out a way to be competitive and straight up copying will only ever get you at parity.

We’ve been using Zoom for a few years too, and if you’re running a moderated test you can actually give mouse control to the tester and have them test while you record. It’s quite easy!

Imagine you were talking directly to the designer and engineer who made this. Would you laugh out loud at them for using stock photos? Or would you ask why they chose those photos and provide alternatives to help improve the design?

Even if your blog post goes in to this you can’t rely on someone reading a tear down AND a long-form blog post.

It’s your content at the end of the day, but I’d be much less receptive or outright hostile to someone being a jerk in a design critique.

There’s a term for that — Agilefall. Teams that take “a bit of both” don’t usually fare well because the methods are at odds w each other. Do you want visibility on the future designs or are you ok w quick response?

If you do vision docs and the work comes out according to plan, but you use “sprints” then congrats - your agilefall. You probably have bugs up the butt, rigid yet somehow still unclear domain ownership, and you attend sooo many meetings.

I’ve seen it time and time again where companies cherry pick methods like they’re smarter than the ones who wrote the book and end up w a nightmare eng culture.

It’s better to pick a method when a project or product scope begins and stick w it. Same w other methods like ShapeUp.

Hey Marina — you are not alone. I 100% agree, and haven't found any designer that didn't find the JTBD framework completely confusing. There are two problems with Jobs to be Done that are contributing to this confusion.

1) There are actually two completely different product mantras using the term "Jobs to be Done". The first, and most useful interpretation, comes from Clay Christensen's book "Competing Against Luck". In it he outlines how people hire products to make progress in their lives — often so they don't have to do the job in the first place. I highly recommend that book. It's a pretty great and useful read to help anyone designing and building products and services to focus on serving customer needs.

The second mantra is Tony Ulwick's version, which is essentially arguing for job stories instead of user stories in development (see confusing point #2 below).

Here's a much better explanation than I can give you: https://jtbd.info/know-the-two-very-different-interpretations-of-jobs-to-be-done-5a18b748bd89

2) The second problem is with Tony Ulwick's version of JTBD. To be blunt it's... really not that useful. It misses the point — users often don't want to DO JOBS. They want to solve a problem so they can move on with their life (this is why people hire landscapers and gardeners — they want a beautiful garden but don't necessarily want to learn about botany). Tony Ulwick's version of JTBD does not capture this well.

It reeks of "thought leadership" baloney. Essentially I think he repackaged the standard design language — user-centric design and user stories — in to a lateral system of job stories. Largely who benefits is Tony Ulwick as a thought leader — running workshops and selling programs explaining the system. The big problem is that it risks encouraging product people to miss the point when designing products because jobs are not often the point of good design in the first place.

IMO user stories popularized by Alan Cooper's user-centric design is just a simpler, more focused approach. It helps you advocate for the right things as you discover them through user outreach, testing, and research.