Ghost in the Pixel

Uday Gajendar's musings on interaction design

Critical facets of a design

Every design has three fundamental facets that serve as a framework of analysis when identifying opportunities to evolve the design further, or extend it into families or standards for related designs.

What is inherent: This pertains to the product’s DNA that define its character/persona/voice and its reason for existence. Strongly correlated to product/company brand. Concerns its purpose and core functionality, expressed in successive layers of materials & interactions within the product. These are the qualities and natures.

What is emergent: This is the value that emerges in usage by the intended audience within a given context. The benefits, consequences, emotional/psychological impacts, the resultant quality of experience. These are the values and principles.

What is persistent: The material attributes of the product (visual, structural, formal) that persist across the family line or successive evolutions. These are practical and durable.

No comments

Design needs a (project) runway

To properly take flight and thrive in the upper levels of product/user experience excellence atmosphere, a design needs a significant amount of runway (to use a very extended airplane metaphor :-)…What do I mean by this? Simply put, there’s need to be thorough time, discussion, collaboration, and exploration of possible solutions before settling on “the design solution” to be implemented. Too often PMs and Devs simply want a quick easy fix to solve some bug and then push it out per some pre-determined timeline, thus ignoring the need for proper design engagement and iteration.

That “runway” is the social and chronological space for the design to coalesce into a form worth lifting off. Time is key element, setting up a wide boundary for opportunities of exploration. But also there needs to be social/collab space of discussion, interpretation, identification, iteration, review/feedback, etc.

And within corp environs featuring multiple products, this runway may require discussions with other designers, evaluation of patterns/standards, ensuring consistency of visual and behavioral approaches, with outlets for inventing new standards if necessary.

To get a design properly airborne, there needs to be a sufficiently long runway to get it up to speed properly so it can thrive in production and implementation. Otherwise, the risk is a design that hits some bumpy turbulence with broken visuals, unaccounted or clumsy interactions, missing features/paths/flows, and lots of bugs unnecessarily filed and triaged (which translate into future patches/updates that jam up schedules, etc.).

No comments

“Tomorrow” is not a schedule

Ask a Prod Manager or Engineer when a “design is due” and the response is usually “yesterday” or “tomorrow”, with little hint of sarcasm. The fact is, that is utterly useless info and counterproductive to deep multi-disciplinary collaboration towards solving problems in a meaningful way that actually matters. Indeed, such a glib approach to time is a grim sign of professional disrespect and ignorance of what it is that designers need and value most: TIME!

It takes time to sufficiently gather the core business & technical requirements, and extrapolate priorities for further investigation and define prelim research and design studies.

It takes time to frame the problem, generate initial concepts, explore directions and iterate accordingly, with feedback.

It takes time to gather that feedback and review and respond accordingly. With multiple rounds if needed, per problem scope.

It takes time to reflect upon designs created, in whatever level of fidelity, to step away and revisit with a fresh eye/mind the next day…This is especially true for visual hi-fi solutions whose nuances and subtleties across screens/devices can have serious consequences downstream with graphics production.

Because it takes time, Design as a process phase and professional activity has to be properly accounted for in a product development schedule, plain and simple. A schedule has a sense of expected duration, with key moments of review/delivery/feedback itemized, an overall movement towards completion. It is in effect a narrative of the process, with multiple moving pieces/players coordinating against that narrative. Without a scheduled-in place for design, it will be dismissed as mere cosmetic lipstickery, with styles/graphics slapped on as an afterthought, without addressing flow/interaction/architecture/service issues. And if not enough time is properly allotted, that is exactly what will happen, like it or not. Design in effect becomes a meager farce, not the enabler of positive change. And believe me, no designer worth her salt wants to do that, but will be forced to if necessary, sadly. “Tomorrow” is not a schedule, but proactively coordinating a planned way to engage with designers can help PMs and Devs achieve a well-developed product that serves tomorrow’s needs.

No comments

Next Page »