היום אירחנו את עמית אלישע - מנהל מוצר ב-outbrain לשיחה על מוצרי אינטרנט ושימושיות.
הקובץ כאן
תהנו
- העברנו שאלון קצר בינינו על המוצר האינטרנטי החביב עלינו.
- מי מעצב ומי מפתח (מי ברכב מי ברגל).
- דיברנו על בלסמיק - כלי לעיצוב ממשק משתמש.
- "שחרר אחי!" כן??? "זה לא מוקדם מדי?" - איך עובדים עם early adopters ?
- איך מקבלים משוב ממשתמשים. בדיקות A/B.
- מתי צריך להגיד למשתמשים... "רק משה יודע מה טוב בשבילך".
- תהליך הרשמה - דוגמה לאיך לעשות את זה נכון.
- מי רוצה את רישום המשתמש שלי - מה קורה עם open-ID .
- למה לעזאזל אין מקום אחד לרשום אותי ואת ההסטוריה שלי.
- פיצ'רים לעומת מטרות - האם אני מתחרה על מספר פיצ'רים?
- כמה שפחות פיצ'רים - 'אפל', האם זה לא הורדה לצורך הורדה?
הקובץ כאן
תהנו
Interesting podcast, guys. Very enjoyable. Thanks.
השבמחקBut a couple of things bothered me...
First, you talked about two ways of doing design -- either have talented developers who can also design, or the product manager designs and the developers develop.
There are other alternatives! There are also other kinds of designers (not just visual or graphic designers). Interaction designers, for example. They design how the application _behaves_. Maybe being a generalist works OK in small teams, but once you get above a certain size, specialization starts paying off.
Second, finding out what's working (or what's going to work). You only talked about quantitative metrics -- A/B testing, web analytics, etc. There is another whole world of testing that you didn't mention. The most important omission -- usability testing. How do you know if users can accomplish the tasks they need to do? Watch them while they try to do it! You will quickly see where any problems are.
There is also the world of user research (which is done before you start building anything, in order to discover the users' goals, which you mentioned at one point). Things like interviews and contextual inquiry. Ethnographic studies. Etc.
I also have a bit of a problem with 37 Signals :) Sure, lots of people love their products, and many people are drawn to the "Getting Real" way of doing things. But those guys know what to build, what features to include, because they are designing *for themselves*. They are their audience.
For many applications, this is not the case. Which means you need to know your users. If you don't already know them, you have to get to know them. How they work, context of use, etc. This means doing user research. And like the Panasonic example showed, the best thing is not to ASK people, but to WATCH them.
Cheers,
@martinpolley
Hey Martin
השבמחקNice to see you writing here and that you are safe after driving the car I sold you ;-)
I think you are right - A/B testing and analitics are not the only methods to get feedback from your users. usability tests is a very educating one about your users and I remember watching over users shoulders in shopping.com. however - it can only work if you have a representing group of users near you and you can easilly arrange such test. If the group is too big or too far it becomes impossible to do it and will be very similar to the analytics stats.
I generally believe that every product should reflect a vision and a goal to fulfill the vision. If this goal have a metrics that you can measure - make sure that the change you do improve these metrics.
otherwise... something is probably wrong.
Thanks for the input and.... keep listening.
Ori
I'm not sure that distance matters so much these days. There are more and more tools for remote usability testing. And group size does not have to be big (though the more representative it is of your real users, the better). You just need to do enough testing such that you stop learning new things.
השבמחקThis testing does not have to be hugely formal and expensive, either. It can be quite informal and "guerilla".
There's some debate in the interaction/UX design community at the moment about analytical-driven design vs relying more on designers' creativity and instincts. I don't think either side is 100% right -- you need both.
But (well-done) usability testing will tell you things that analytics can't tell you -- analytics may tell you that there is a problem, but not WHAT that problem is.
But you are absolutely right about vision. The vision, the lighthouse on the horizon, tells you at every step whether you are getting closer to where you want to be or further away. There is another excellent podcast by Jared Spool at http://uie.com that talks about this a lot.
Another thing that I forgot to mention -- Balsamiq is good for that initial ideation (especially if you're not a pen-and-paper person), but there are other excellent tools that are more appropriate for other stages of the process. For example, Axure RP is a really powerful tool for making prototypes (with things like dynamic panels within pages, and various other kinds of rich interactions).
Anyway, keep up the good work with the podcast.
Cheers,
Martin
Hi Martin!
השבמחקThanks for the comments!
As Ran has mentioned at the beginning of the podcast, we knew we are going to fail covering everything going into this subject.
I agree that the design should initially be driven by usabillity testing and at a later stage - analytical.
I personally prefer to see the next stage, after ideation with balsamiq, in HTML and itterate from there.
Of course it works best with smaller teams but even larger teams are adopting the agile manifesto.
I guess there is no "right" way, as long as we keep developing great applications for a better internet :)
Hi Amit,
השבמחקThe benefit of having a quickly-thrown-together prototype as a stage in the middle (which can be in HTML, of course) is that you can use THAT for usability testing, instead of having to build the real thing and then go back and fix it when you find problems (which is usually more work).
Cheers,
Martin