Hypotheses formed when conceptualizing a solution to a problem are guided by its’ constraints, interpretation of research conducted against assigned metrics and ultimately by embracing uncertainties. Regardless of the confidence we may have in that the solution we are envisioning is valid, our processes still consist of first evaluating multiple design solutions to the problem in early stages of the project.

Then, at one point or another, a decision is made, particular approach selected and implemented; leaving those less fortunate ideas in the discovery stage, never to be seen again. How sad – I believe they deserve better.

I will examine that particular moment when likelihood of one variation to succeed is determined as higher than that of another; identify why and how that decision is made and justify that sometimes not selecting any one particular concept, but proceeding with two or more candidates is the most viable option.

Once we establish that having multiple design solutions, is a good thing, and only then, I will examine how we, the solution providers, may capitalize and how the users, therefore stakeholders will benefit.

Continue Reading

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

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