Responsibility in ownership

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.

Whose hat is that?

More often than I would like to, I get handed a half-baked design concept some analyst or project manager has cooked up in order to avoid miscommunication. These magnificent compositions of screenshots and annotated red boxes containing though provoking comments (e.g. “Move to left slightly”) are usually interpreted as an insult or admittance of a failure on behalf of the author. Insult if whoever is responsible for communicating the requirement believes that I lack in mental capacity to understand what their intentions are and a failure on the behalf of the same if they are unsure of their ability to properly express ideas.

As I am yet to see a job description for an analyst or a project manager that calls for putting together visual compositions I am safe in concluding they have no business doing it.

They are not skilled at it, not paid for it, and almost always overlook standard design practices, consistency with other elements of the solution etc.. It wastes time and leads to nothing but headaches and arguments down the line; or worse if timeline is scarce – implementation of faulty solutions and ultimately miscommunication, the very thing they were trying to avoid.

Miscommunication and oversight

So why do they do it? More times than not, the prime reason is that they were in a meeting you were not in, and were told what needs to be done. Following this missed opportunity you had to ask the client directly for any clarifications, bounce ideas, discuss how the user might react to XYZ and ultimately eliminate one person in the He Said – She Said chain of events, the person who was there, and who was entrusted with communicating the requirements sat there and played a role of an expensive voice-recorder.

Having the right people responsible for the right things lessens possible oversights and more importantly it provides an opportunity for direct, meaningful and timely specification input on how much work is required, how to best split up that work, what resources need to be allocated and so forth.

The specification

An act in which set goals are to be communicated to the rest of the team is called requirements gathering, and it usually results in one or another form of a specification document. It is the role of a B.A. (or similar where applicable) to translate goals, which are the desired results of our solution’s equation, into actions. The environment and resources available to us are the equation factors and their allocation belongs to the managers and architects. The formula however, a way in which we derive the desired result is not for an analyst, a manager or anyone else but designer to define and execute.

Fidelity versus vagueness – Level of specificity a requirement carries can be a curse and a blessing at the same time, if too low – open ended solutions that do not meet business goals can happen; too high – and we eliminate ownership, innovative solutions and with them any chance for real design critical thinking to occur.

The goldilocks measure clearly states the problem but facilitates interpretation, feedback input, critical thinking and risk taking.

Risk – balancing research and intuition -
Research has shownour previous user studiesdata set analysis point to … and other similar idioms as well as established (business as usual) practices more often than not limit the opportunity for a design to explore and reach its potential.

Risk taking is an essential part of any business strategy and same applies to design processes. Stepping outside of our comfort zones and flexing our intuition rather than reason is a most common way of breaking through local maximums and yielding in stronger experiences.

Taking a chance on something is a bonafide method of establishing and practicing ownership in that thing.

Tackling challenges

Best design solutions are conceived by designers. Can we at least agree on that? … Let’s pretend we can.

So why have designers second guessed or even worse mentored by those who have little to no experience in design. You may argue that designers often don’t consider certain requirements, use contexts etc. and this may be true in some cases, but where it is, it is due to their inexperience in having responsibility or stake in the success of solutions.

To test validity of a design we need to set it free. But what if it fails? Then you try something else. Important thing is that it might not fail, it might excel. But design will never soar to its full potential chained to the ground by latest best practices report or known optimization studies; it will only do so if free to explore all possibilities.

As any craftsman will tell you, reason why they got good was because they took pride in their work and they got that pride through an endless trial and error processes. Absurdly enough, the digital media, one discipline that is more dynamic by nature than any other treats it’s designs as static solutions that will live forever. We need to change that.

Solving equals motivating

One of the reasons why I cringe so much at over specified requirements, overly controlled revisions / optimizations is that it scales down the role of a designer to a labor rather than a knowledge worker. A lot of designers today are not more creative than a robot. They receive a set of instructions and without questioning them or doing any critical thinking go off to production just as if on an assembly line.

Virtue of design, any design, is it’s capacity to take something that isn’t and make something that is. Solving a problem on your own, creates a sense of pride, ownership and with it a desire to see it succeed.

Imagine being a carpenter building a baby crib. You wouldn’t go to a store and get some box, unpack it, read the instructions, and put it together; if you did that, you wouldn’t be a carpenter, you would be just someone who knows how to work the tools. What a carpenter does is recognize a baby needs a crib, grabs an ax, goes to the forest, gets a tree, treat it, cut it, work it, and give it form and function.

Power struggle

Having an aura of credibility or specifically proven value in your role is something that can really boost your confidence. It encourages you to make riskier moves, admit when you are wrong, and adapt to challenges more quickly. Gaining credibility it is the hard part.

So how do we go about establishing, no… demanding the responsibility that is inherently ours? One way is to increase your credibility by implementing incremental changes and savouring every win; but. that only works if you either have some decision making power to begin with. Alternatively, you can stand your ground, refuse to do it any other way and put your behind on the line.

If you have zero input in the inception of the project, (and there is no shame in admitting that,) you also have zero input in the design of the solution. Acceptance is part of the battle, or so they say.

Just running the engine

Some of us, esteemed digital designers of this world, consider ourselves to be a different breed from other designers, and regretfully not for better. Lacking in pride and self-respect gained from genuinely creating solutions our egos have been stripped, and with no courage that comes from it we are scared to challenge instructions handed down and take risks.

Meeting deadlines and beating forecasts, pumping out design versions etc. has somehow become our primary goal, it outranks careful considerations, testing and feedback implementation… which is fine for some, but not for others.

Those who resist just accepting whatever is handed down ultimately have the opportunity to prove their worth. Not to say instructions are always wrong, but you need to establish that for yourself and derive decisions that will guide your own process onwards. Sometimes you may reach a different conclusion that yields a worse outcome, but at least you didn’t just sit there, you took action and hopefully learned something.

Establishing core principles

Before even starting a battle about who owns and in turn is responsible for which decision, a business must first establish a clear image of its core values (or perhaps even better just one value) their product or service stands on.

Principles are an interesting thing, they can help mediate arguments, create a team oriented environment in which everyone is striving to achieve the same goals and therefore value each other’s ownership more, Different people in the organization might interpret the principles in a slightly unique way, and that is perfectly fine. Interpretation is what encourages discussions and arguments within a pre-established framework of checks and balances power structure.