elishacook

9 ปีที่แล้วdiscuss

These read like brand attributes to me. They are too general to be design principles. It’s not clear if the interaction design principles are intended to be universal or specific to Airbnb? If the former I must call shenanigans. There are no universal design principles.

elishacook

10 ปีที่แล้วdiscuss

I agree. It's not a mental tax to read a word we recognize. It's not like we have to sound it out letter by letter, we recognize its form at a glance. It's more taxing to maintain a mapping for an inherently meaningless single character.

Although there are some single characters that do have meaning due to long time convention such as 'i'.

elishacook

10 ปีที่แล้วdiscuss

I can relate to this. You see it in a lot of domains. I see two concepts that apply: Practice/Performance and Generation/Synthesis.

To be a musician you must practice, but you must also perform. These are two different modes. When practicing, the goal is to improve a specific technical skill. You don't concern yourself with expression at all. You will repeat the same passages over and over and many exercises sound really terrible. When you perform, you put your trust in your training and you access an intuitive part of yourself to add feeling and nuance to your playing.

In design thinking, it is common to split activities into generation and synthesis. When generating, you recklessly explore possiblities, tossing them out, following blind alleys, making weird connections. Synthesis is the process of evaluating the generated ideas against some framework, such as goals or known models, finding patterns, simplifying and making coherent.

We need all of it: practice, performance, generation and synthesis. Experience brings a sense of when each mode is appropriate or needed. Being explicit about which mode you are working in removes the stress from attempting to practice while you are generating or similar dissonant mixes.

More concretely, a user-centered process has brought a lot of this mental framework to development for me. Step one is never setting up a test harness, it's understanding the user and their goals, even if the user is yourself.

Everything else flows much more easily from this starting point. You can base your decisions on how they will affect the user instead of on "best" practices that may not have the best outcome in your situation. Things like precision, speed, fidelity, automation, complexity, stability, even whether or not to build something--all involve trade offs that affect the user in different ways. You can experiment more freely knowing that you will evaluate your experiments in terms of their utility for the user.

The art is in applying this left-brain-right-brain dance to trace a path through all the complexity on behalf of the user.

comments