Data Driven Creativity

When crafting solutions for users we understand that relying on hard metrics, ecosystem contexts, engagement patterns etc. is something we must do to maximize impact and reduce risks. However, when it comes to designing processes through which we create, we pay little attention to how we schedule our own time and allocate our capacities. By solely focusing on estimating the actual design work (how long it takes us to code or draft something) we often underestimate or even omit accounting for research stage, time needed for meetings, feedback gathering etc. Once the budget (if you are freelancing) and/or amount of time is agreed upon, it can be hard and rather uncomfortable to renegotiate in the middle of the project when we realize time was spent on something not foreseen in the appraisal. This leaves us with a choice between lesser of two evils, either underprice and work extra or sacrifice time we allotted for design.
Continue Reading

As hard as it may be to refrain from grabbing someone else’s mouse (metaphorically speaking) and start doing their work, we must let people execute the functions their positions warrant.

In order to avoid wrong people making design decisions, tripping over each other, duplicating efforts, committing to faulty solutions because personal preferences of clients (internal or external) we must make it known who owns which part of the problem as well as solution.

Clearly established roles, opportunities for timely and meaningful input, specifications that don’t hinder innovation but avoid ambiguity, established critique practices and expectations will all help us in establishing a sense of personal ownership and stake in our creations. More importantly, by adhering to and facilitating each other’s ownership we will have eliminated hindrances in enabling us to achieve experiences and potential that a solution can aspire to. Continue Reading

First, a clear distinction needs to be made between design delivery and deliverables. Deliverables such as wireframes, visual design comps, etc. are just artifacts of the design process and not the final design nor a part of the end user experience. Only purpose artifacts have is to facilitate communication between designers and other team members.

Delivery in effective design processes goes beyond artifacts through the implementation and production stages to the user; and only at that point does it initiate the use stage of design life-cycle.

To ensure our designs are effective we can’t stop at deliverables and must extend our scope through delivery. Continue Reading

I’ve been consulting on a project that will output native applications running both on Windows 8 and iOS. One of the main concerns is ensuring experience and interface consistency in cross-platform design, which can be rather tricky when those platforms have design principles standing in direct contradiction to each other.

Key difference between iOS and Windows 8 I found while digging through the guidelines is how they relate the users to the physical world. iOS tries to replicate the world we live in by designing digital interfaces according to what the user is familiar with. Windows 8 takes a different stance, it recognizes that physical and digital are not the same and should be treated very differently. Furthermore, the crazy Microsoft guys go as far as saying we can design digital better than physical:

Be authentically digital

Take full advantage of the digital medium. Remove physical boundaries to create experiences that are more efficient and effortless than reality. Being authentically digital means embracing the fact that apps are pixels on a screen and designing with colors and images that go beyond the limits of the real world.

Metro Style Design Principles

and I completely agree. Regardless of cost, is it practical to impose (physical) limitations both on our design capabilities and also on what we can offer to user’s experiences ? I shout no, but also recognize the danger of an ever increasing learning  slope. Continue Reading

Microwave Design

Ad-hoc design, or as some people say “design-by-committee” looks at creating solutions to very specific problems. If set in an environment that compromises evaluation of solution iterations for “just getting the project out the door” and not ruffling any feathers whilst doing so, ad-hoc can be very dangerous. It will negatively impact the success of projects, and with it team moral; through highly inflexible and often poorly constructed requirements made by the wrong people in the organization.

Workplaces that commonly nurture the culture type I described are “in-house” teams. Existing in a strictly defined structure, insecure middle management and executives have limited perspective as well as incentive to examine possibilities of improvements suggested from post-committee team members and are almost never willing to challenge the status quo of ineffective decision making authority structures. It’s not their fault, they’re just managers after all, they don’t know any better. They implement linear processes that utilize rational thinking  and expect great innovation to just happen without realizing they are actually stifling it.

Result as expected, is a mediocre (at best) solution, that is pushed to production cycle doomed for failure from start because teams which have to implement this solution do so through a microwave process of cooking up aforementioned shitty requirements on high for 2 minutes per pound and are left unsatisfied with the outcome. This is primarily because they recognize a better recipe exists. More delicate process in which care is given to each ingredient by individuals with unique sets of expertise, who are assigned appropriate authorities and derived responsibilities.

Continue Reading