• Register
• Log in

Spill

The “Anti-Methodology” – A different approach to application design?

Ok, I’ve been hesitant to post this mostly because I don’t feel methodology is a point of competitive differentiation. I do believe great people always do great things and methodology provides a framework to commoditize redundant processes as a platform for them to stand on. But what if there are never redundant processes? What if application design is truly unconstrained by development processes (artificial or not) and instead addresses only the needs of the system (users, business, technology) in an exactly appropriate manner? That’s how we roll when we innovate. 

This post isn’t about Agile or Rational Unified Process (RUP) or any other waterfall, hybrid-waterfall, swim-lane, or “Wagile” methodology. Ours is the “anti-methodology.” We steal as needed from all of these processes. You can learn about them here.

Metaphorically speaking, we like to think of our teammates not as “swimmers” or “runners” but as Athletes with medals in specific categories. We have medalists in information design, system architecture design, visualization, product strategy, user strategy, management, and so on. We see it this way because each and every person has enough experience to be able to swim and run with the rest of us through the project iterations. They may not be a medalist in running or swimming sports, but are likely with our team because of their excellence in another. Regardless, they are brilliant, driven, and eager to challenge ambiguity (remember there is no spoon). 

Often recruiters or job applicants come to us talking about a specific role like, for instance, a user experience architect. We’re smart enough to realize that we have to address the global community with a shared perception of what a person’s role might be when working with us, and in turn are frequently rewarded with eye-rolls and explanations like, “That person just doesn’t exist.” or “There is no way we can find a designer/programmer/information architect for you.” I wish you would believe me when I say, they do – I’ve hired every one I’ve found. Another popular response is pointing out the “Jack-of-all-trades” dilemma. Respectfully we must point to the origin of the quote and its entirety, “Jack of all trades, master of none, though ofttimes better than master of one.” Is that threatening to you? It shouldn’t be, there is plenty of opportunity for “masters of one”; just not here. 

We aspire to become the Polymath. I would even dare to say, it’s a requirement in today’s rapidly changing technological landscape. If you the business or the individual hope to flourish in our ever-commoditizing culture (recession or no) you have to provide value that cannot be reproduced cheaply locally or from afar. Industrial design is experiencing this as China begins providing viable and cheap design resources. 

Let me refocus…

When talking about the activity of “wireframing” we have been forced to acknowledge that this activity was created for the right purposes and has since become the crutch of a process that is likely slow, costly, and to some extent inefficient. Wireframing to us is bad drawing (sorry guys, it hurt us too). Our team starts prototyping solutions on the first day of the project in varying levels of fidelity (you might call a prototype “wireframey” except it encapsulates motion concepts, toolkit ideas (i.e. ESRI mapping control), aesthetic goals, and it only answers a predefined subset of the entire solution. The prototypes evolve (in their natural medium) to become the final product so we might actually make this prototype in HTML or Flash. As for use cases, user personae, and functional specifications, we build small prototypes and test them frequently. We don’t believe in document creation for the simple fact that the document is outdated the second it hits the printer (plus we like trees). We believe any method that forces transfer of knowledge is not LEAN and to top it off we have yet to find a client who isn’t really designing an application for people just like themselves. 

(pause for rage and flaming)

There are times when we document applications after they have been “in the wild” for long enough to stabilize (testing never stops), so don’t freak out entirely. We really want to illustrate and challenge the industry to rethink the status quo. Another example of our challenge that many in our profession will balk at is that we have had great amount of success focusing less on the user demographics and more on frequently iterated prototyped task flows and testing. People are too complex and diverse for us to presume we can capture anything actionable in a document that takes a month to create. 

So, to wrap up this installation, from ideation to realization there are only small cyclic iterations that evolve the solution(s) in their natural medium to their final state. We invite you to explore a world without walls of role description and hope you experience innovation and client satisfaction like we do. Stay tuned for my next post that illustrates how we integrate customers into the design process. It will be called “The We in Innovation.” 

NOTE: I will caution the experimenters out there, we have been developing this process for many many years and have burned out a lot of great people figuring it out. We’ve finally made it but this journey will require some bleeding. Good luck, and God Speed. 

Posted by Joseph Juhnke on April 22, 2010