Some say there is a turf battle coming, I think it's a lack of understanding, and I think it's already here.
The battle we (they and I) speak of is the vision and strategy for digital products. We have these roles like Information Architecture, Interaction Design, and Visual Design... not to mention prototyping and writing code... then we also have these partners in the shape of Product Managers.
It's the difference between the 'product' and the 'experience' that's important to understand. There are process problems that the software can not solve elegantly... but with vision, and potentially through the interface, we can. There lies, just outside of your app, your site, or your software logistical problems... problems in space and time... problems that surface only through field work to understand the context of need and use. Being there, watching, listening, asking questions, and then putting the prototype in their hands (you know who) is the best way to try, fail, learn, try again, and ultimately... provide the solution.
The user's experience... it's much bigger than the product.
13 November 2013
When I was just a youngster, I spent 12 days deep in the woods of Canada with a bunch of buddies and canoes. When we finally surfaced from the wilderness we were told that the war had ended. A year later, after two weeks in the mountains we surfaced to hear of our President resigning. Both were huge events. And, we had missed both of them, or had we? Those news epiphanies almost overshadowed the fun we had had on our adventures. Years later, I remember recalling the freedom I felt as a teenager during those trips. I often wonder if the missing weight and tediousness of worldly events weren’t at least a small part of that freedom.
I’ve read at length Saul Wurman’s writings on the anxiety of information and overload. But I wonder if we’ve wandered into something else. Something more burdensome.
I was in grad school when the facebook thing took hold. This allowed me an inclusion that my working peers were not privy to. An early adopter one might say. In the following years facebook served me well as a conduit to my friends and family while moving about the country for corporate jobs. Just recently, I stopped all of that and have not looked at facebook in a few weeks.
We now have a shared ubiquity and awareness of our friends and family that is unprecedented. Frankly, I’m not sure you can really have 300 friends, though my friend Juli (and oddly a friend of her’s named Matt) have a remarkable and unique capacity for names and faces that is well… both wonderful and a bit intimidating. They both literally know and recall hundreds of people… but I’m well off track.
Do I really need to know that someone I once worked with for three months just had a great time at Pitchfork (an indy music fest in Chicago)? Probably not. Is there an effective way to filter them? No, not with offending them (de-friending). It’s just too much… and that’s not even considering the bombardment of ads and political agendas. And it’s not that I don’t care… I just don’t think I have the capacity. I’m (and should be) much more concerned with issues inside my household and with the people I see and hear from every day and week. I feel relieved and not only less distracted… much less stressed. I’m pretty confident that those who care, know who to find me… and we’ll have much more fun catching up face-to-face.
11 October 2013
I was reading an Agile blog this morning. I know I shouldn't, but I did.
The author was complaining about a product manager coming to the group with fully thought out requirements and stories that were too long and complex. And again, I thought... is this about control and making requirements up as we go along?
For any project to be somewhat efficient and effective we must have some sequencing and some expertise that drives decisions. Group think is aggregate. If you understand statistics you know that there really is a very minimal amount of understanding that comes from averages. Similarly, group or aggregate thinking renders severely compromised decisions. Higher levels of expertise should be allowed to take responsibility and make final calls. Further, some level of individual work (divide and conquer) must exist. A team does not always need 5 or 6 people standing at the whiteboard to execute the simple or most detailed of functionality.
There is an element of sequencing that makes sense as a project progresses. Requirements come before solutions. Sketches come before code... it’s critical in any process... even agile and lean.
In most software development work... 50-85% is fairly standard and doesn’t require huge efforts of innovation. Many times meeting expectations (quick adoption) is more important than improving process.
02 October 2013
We are still witnessing an agonizing fall from mobile supremacy. Reading yet another article about the demise of the Research in Motion (RIM) I was struck by what seems obvious. Their quick rise was due primarily to a happy accident... the post 911 logjam of the traditional telecom networks. Days after 911, the US government began to distribute thousand of Blackberries to government officials because RIM had built their own network that was under utilized and had plenty of available bandwidth. That market advantage wasn’t bound to last.
The perception of Apple (RIM’s primary predator) having the audacity to build a phone was seen as very high risk. It was sooo outside of their expertise... they weren’t part of the sanctioned club. It’s interesting how many people, and especially people driving strategy, perceive risk. Risk is not reckless... it’s not guess work, and it’s not typically without extensive calculations and homework. Most interpret skydiving, scuba diving, rock climbing as risky endeavors. Yet ALL of the people I know that undertake these hobbies are as careful, skilled, studied, and prepared professionals I’ve ever worked with. They are way way aware and cautious about their approach (to everything frankly) and the possible outcomes.
But the real story here is how hardware and software need to work together. Blackberry fell in to a trap that Motorola had long honed... developing hardware in a vacuum and sharing the ‘thing’ to their software development team once it was near completion so that they could design software. They saw it has a platform rather than an integrated product offering. Motorola designed and manufactured incredible hardware... for years and years. Where they fell down repeatedly was in the development of not only good user facing software, but how it integrated with their hardware.
01 October 2013
Many managers, in a struggle to accomplish completion of projects insist that product requirements be locked down prior to the process of solutioning. Often this is a symptom of a disconnect between product management and design.
Locking down requirements moves a problem from one that is complicated... to one that is either complex or merely simple. It reduces the variable nature of problem solving from one of multiple solutions to the potential of a ‘right’ solution. But, it does that using unreal or arbitrary constraints. Things change. Our understandings change. And the ‘locking down’ of product requirements ignores that. It isolates the definition of the problem we are trying to solve to an instance... an instance that may pass us by as a mere blip on the path we travel.
I’ve been quoted as saying that, “locking down product requirements is lazy management”... and I stand by that. Reducing the problem to a non changing situation, and reducing our solutions to a stagnant state of understanding reduces out ability to solve the problem optimally. It changes the entire focus from finding the best solution, to getting the job done. That, is not an optimal compromise.
05 September 2013
I’ve been struggling lately with the notion of ‘no heros’. The concept caught my eye when reading the book “LeanUX” and I hesitated to pass quick judgement. After all, one person’s hero can be another person’s prima donna.... so some level setting in definition is in order.
Individual contributors need the opportunity to rise up and have impact. When building a cohesive, collaboratively rich, and productive, work culture public acknowledgment of ‘work done great’ is a critical part of the formula.... and MUST be encouraged.
In the online and software space, many of the designers I’ve worked with thrive on this... as do product managers, project coordinators, and certainly developers. Granted, some like to revel in private victories... but high performers that find ways to break through in critical moments will always be heros to me... and I’ll continue to celebrate those contributions.
10 July 2013
I like listening to Patsy Cline or watching Gone with the Wind on occasion. But lately, I haven’t felt all that nostalgic.
Watching new products as they are released and reviewing a ton of interaction design work recently I am struck by the observation that a large part of our industry is stuck. They simply aren’t progressing.
As one tiny example... why are we still focused and utilizing menus and buttons so prevalently. Front end code has advanced... we can now make objects actionable... but why aren’t we? Have we flatlined? Have we forgotten Fitt’s Law? Or did you ever learn it in the first place?
There is huge demand for people that can organize and design the plans for software. So much demand in fact that a large part of our field is now staffed by people that don’t have adequate training or experience. They are smart, quick to pick up on patterns, and often very good with clients - but they don’t know how to explore, invent, or take risk, and they don’t have enough foundational understanding of human cognition, behavior, or the notion of context.
While the industry (UX, iX, IA, whatever) is maturing, we aren’t yet mature and we shouldn’t stop innovating. Those huge libraries of patterns, styles, and standards out there aren’t ‘safe, aren’t stabilizing... they are stagnating.