Caltech STUDY: What you see is what you buy – how a simple design trick affects consumer choices | EyeQuant Blog.

Next product will have one use case, one sort of user and one sort of registration. I promise.

I’ll assume you’ve validated your great idea with customer interviews. You’ve had some decent feedback and you’re ready to go.

What do you need now? A pen and a piece of paper. Just sketch your basic UI. Don’t overthink it. Keep it simple. Make sure every page has:

• One clear major action you’d like the user to take
• Some basic navigation to the main features
• And maybe discovery navigation if you have something to discover. You probably don’t.

But  this post is not about information architecture, UI design or UX methodology.

Whatever you do at this point, it will have major flaws. Even if you have years of experience. I can’t explain why. That’s just the way it is.

But it doesn’t matter because your first UI sketch should have only one goal: to start a conversation with people who might be users / customers. A conversation about their problem around a piece of UI. It changes everything when people are is user mode. Listen again. One of the main issue designer, programmers or product people have at this point is that they’ve already bonded with their sketch. Instead of using it as a conversation starter, they think it’s about improving what they have.

But you have nothing and now is the best time to start designing your product from scratch all over again. Don’t be emotional. Just take it all in and go back to the drawing board. If that means 90% is going to the trash, who cares. It only cost you a few hours of work. A bad start and rapid programming of an “ok” design will cost you way more. And from there, every little step will bond you more with your design and will make it more difficult to start from scratch.

Your first sketch is not your UI. It’s not your product. It’s your visit card to meet people and listen to how they feel about the problem when looking at a product UI. Not how they feel about your UI. About their problem when they are in user mode.

Don’t code. Not yet.

Lettre ouverte envoyée à Philippe Duval, président et directeur général de la SAQ, au sujet de leur application iPhone.

Cher Philippe,

Je dois vous faire part d’une constatations troublante et ma foi inacceptable: l’application iPhone de la SAQ n’est simplement pas à la hauteur de ce que l’on s’attend de l’institution chouchou des Québécois.

Ne vous y trompez pas, les fonctionnalités de recherche sont excellentes. En fait, la performance de votre recherche par code barre éclipse totalement celle de l’application que j’utilisais jusqu’à maintenant. La possibilité de géo-localiser la succursale la plus proche ayant un certain produit en inventaire est un petit bijou.

Mais c’est à peu près tout.

Où sont les fonctionnalités sociales de l’application ?

Pourquoi ne pas me permettre de partager ma liste de favoris avec mes amis et de consulter la leur ?

Ou de simplement partager mes trouvailles sur Facebook ou Twitter ?

Pour ce qui est de la recherche de succursales, vous êtes complètement passés à côté d’un cas majeur d’utilisation qui se résume à cette question: “Samedi soir, 18h20, où est la succursale ouverte la plus proche ?” À quoi bon me présenter les 5 succursales environnantes si elles sont fermées ? À tout le moins offrez-moi la possibilité de consulter leur horaire.

Vu la popularité sans cesse grandissante des bons vins au Québec, vous aviez la possibilité de créer l’application la plus populaire et la plus aimée à ce jour dans la belle province. Et vous avez échoué. Ne vous fiez pas aux données de téléchargement pour me contredire, venez prendre le pouls des 25-45 qui l’utilisent.

Mais tout n’est pas perdu. Tout développeur de produits rêve de travailler sur une application pouvant avoir autant d’impact. Je vous offre de mettre mes 12 années d’expérience en développement de produits, ainsi que celles d’un designer de renom et de 2 développeurs iPhone à votre service pour pourvoir les Québécois d’une application à la hauteur de leurs attentes.

Vu votre budget probablement dilapidé par une agence de pub, tout ce que l’on demande comme salaire est la constitution d’une généreuse cave a vins.

J’ai réservé mon mercredi matin pour continuer cette discussion avec vous. Laissez moi savoir à quel numéro je peux vous rejoindre.

Merci et bonne soirée,

 

Phil Gauvin

I recently hired a promising school dropout. He goes by the nomulous moniker on the web and as Fletcher Tomalty everywhere else. Some late night browsing on GitHub made me a very lucky manager as he’s so far the best hire of my 1st decade in technology. Too bad, he’s not drinking yet

Last week, his 4th with us, he told me I was wrong using the word “ratio” to qualify some metric for the social recruiting product we’re building at matchFWD. I first resisted as he couldn’t come up with a proper alternative and because I was pretty sure it was a ratio. Turns out he was right as a ratio is

an expression of the quantity of one substance or entity in relation to that of another; the relationship between two quantities expressed as the quotient of one divided by the other.

and it differs from a proportion

in that the numerator is not included in the denominator. Thus x/(x + y) is a proportion, x:y is a ratio.

Read more: http://www.answers.com/topic/ratio#ixzz1fAYUo8sv

I think using the right words is incredibly important when programming as well-written and well-labeled code is, in my opinion, the best type of documentation (yet often not sufficient).

But the real thing is: I got schooled by my new hire!

And I think it’s great!

You need to encourage your team to speak up on issues they’ve identified and encourage them to come up with a better solution.

That’s not sufficient though. You also need to fix the issue. And I am faulty, I haven’t yet fixed all the variable names. But you know what? That’s the first thing I do tomorrow morning. Why? It’s clearly not a top priority, the misusage of “ratio” is invisible to users and nothing is broken. It doesn’t matter.

If you want your people to keep coming up with suggestions of improvement, take action when they do or you might just repress one of your best source of continuous improvements.

I am not saying you need to fix every little bits and pieces that one guy thinks are not perfect or you’ll never launch your product or release the new version. They should know better anyway right? Use your judgement but make sure everyone as a voice and that their voice as meaning.

And that’s how you start building a team.

If you’re part of a team or looking for a new opportunity, make sure your boss can handle being schooled by his team.

Related articles

• Scaling GitHub’s Employees (zachholman.com)
• How GitHub Works: Creativity is Important (zachholman.com)
• Knyle style recruiting (warpspire.com)

If you’re a co-founder,  CEO or simply the boss of the company, everything that sucks about it or that fails is your fault.

Don’t even think of blaming the new guy, the young guy or the guy who left for a week in the Bahamas.

If one does not know what to do, is not qualified or hasn’t documented how to re-configure the message queue system, it’s because you weren’t there to make sure things were OK.

So next time you’re about to send an email to blame someone, forward it to yourself.

I have a focus problem like most people who likes to build stuff. Therefore I am glad to be surrounded by people that get me back on track when I talk about nice-to-have or features that won’t really move the needle to get us where we want to go.

But I’ve stopped listening to anyone that do not believe in the product vision shared by my co-founder and myself. That do not believe what we envision can be built and disrupt things (no buzzword intended).

Every time you listen, you allow doubts to creep in. Useless. You have no time or energy for that.

Stop listening. Just Build It.

I always find myself figuring the best route to complete all tasks.

What do I want?

An app to …

• Alert me when I am close to a business related to an item on my TODO (integration with YellowPages API?).
• Integration with Google Maps so when I plan a route (by car, bike or transit), it chooses not the shortest path but the better usage of my commute and my trips to scratch off items from my TODO list.

NOTE: found that old (2007) post about something like that, but with antiquated technology and UX. Give me an iPhone/Android app.

I’ve been working with software engineers for 13 years, more often than not as one of them.

They come in various shapes and types but often as slightly introverted people. Not always the most talkative.

They’re smart people, so if they have a problem, they will talk about it. But if not, they often just do their thing.

I am not a big fan of meetings in general. But I think it’s good to force your team to talk to other devs about exactly what they’re doing, just to get feedback. Maybe a co-worker

• has solved that problem before
• knows a great library to do it
• will tell you it’s simply not worth going that route for X or Y.

So if the office space has been silent for too long and nobody is committing code, start talking. Ask to ignite conversations, don’t wait for them to ask for help.