Boxes and Arrows: Comments by Adam Polansky

Adam Polansky — Mon, 16 Jul 2007 19:31:39 GMT

I’m a big believer in having a starting point for your thinking. It serves as a rudder when things start to get tedious or too micro-focused.

As long as you have a standard to begin with, you have to come up with an argument to depart from it as opposed making up a rule on the spot or being at the mercy of the most charismatic person on the team when it comes to what and why something finds its way onto a page.

It’s not going to solve all your problems and compromise is part of doing business. However, you’d be surprised how often you can close a discussion by being the person in the room with an external basis for a point of view.

Adam Polansky — Fri, 26 Jan 2007 20:02:43 GMT

Nicely organized.

My team is beginning to assess different tools that we can use to close the gaps between deliverables and help us tighten up the integrity and maintainability of our documentation. This article gives us a good way to take a glance at what each tool does/doesn’t do before we dig a little deeper.

I think the key for us (and many others I would guess) stems from Anders’ point that iRise was exceptional for certain things of a certain size but that on occasion, it was more practical to use simper methods of comunicating ideas. We aren’t really looking for something to “replace” anything as much as we want something that can help us be able to respond more quickly when we’re working with larger teams or on more complex applications. That said, if there’s enough intellecual funding in place on the team, and it’s enough to convey concepts in the abstract, then that’s what we’ll do.

I think when a firm lays out fantastic amounts of money for any software or systems, there’s an expectation that it will be used almost exclusively. If not, then why pay that much for it. We have a couple of folks who’ve worked within an iRise environment but it sounds like that expectation of exclusivity turned out to be constraining.

As internal IAs, our different business owners are our “clients”. We need different measures to communicate with each of them. As a result, I need to be able to communicate with different means using different measures that can be either simpe or sophisticated just liek any outside consultant. Your article gives me a better idea about options that can be reasonably and cost-effectively added to a toolbox without having to make room for it by chucking out the stuff I use now.

Adam Polansky — Tue, 12 Jun 2007 21:24:54 GMT

Well done. It’s a difficult reality that the needs of the business don’t always run true with what would empirically inform UX efforts.

It’s the ability to manage those relationships – the compromises and the understanding of others goals, that moves projects into production. Yes, you might have to hold your nose as you identify ad space in your wireframe but you pick your battles. The consessions you make on one item result in the latitude to take a risk elsewhere.

Hopefully, over time, you can influence business owners to see and belive that usable products DO generate more revenue and DO save costs!

Adam Polansky — Sun, 17 Feb 2008 21:30:43 GMT

I really enjoyed your article. I like the way you’ve taken the most common knocks and essentially validated them by changing the context around them. You’re musing on the appeal of Information Architecture was particularly on point for me. It gave me another way to know why I love what I do.

When it comes to being shallow, I’ve talked about maintaining what I call a “willful ignorance” when it comes to back-end systems. By that I mean I try to envision somthing without immediately tearing it down with a knowledge of system constraints. If I can communicate it to someone who is as creative and passionate about software development code as I am about UX, there’s a better chance that vision will be realized. I’ve seen it work.

We’re all such junkies for external validation. Thanks again for what I thought was an afffirmation.

Adam Polansky — Thu, 05 Jul 2007 09:27:33 GMT

Great Interview! Dan & Tom do a good job of illustrating some of the differences between External/Contract/Consulting efforts and Internal efforts. When you are a consultant you have to set certain expectations about what you’ll deliver even to the extent of what it will look like.

They’re going to be paying you by the hour so you have to be more prescriptive at the outset because you’ll use these examples to sell your services and gain the business. You’ll decide what examples to promote based on your assessment of the client’s level of interest and sophistication.

Dan’s comments also suggest that you have to assess their level of imagination as well. If they don’t understand a prototype but they can wrap their brains around a wireframe well…the prototyping tool goes back in the toolbox unless…after you’re engaged and you’ve learned more about the environment, you see an opportunity to get it out and sell the notion.

No single artifact is right for every client and every situation. You don’t get paid because you use a hammer, you get paid because you know whether or not to use it and where to hit!

Adam Polansky — Wed, 01 Aug 2007 14:59:16 GMT

Wonderful article and insight! I think anyone who has been in this space for a while has been in the position of being the “first marine on the beach” when it comes to proposing UX as integral to a company’s success. I’d add a few comments though (what a surprise!).

You mention motivators early on when you talk about users spending their hard-earned dollars to buy your product. It’s also important to be aware if those dollars can easily be spent on someone elses product. I’ve found that reminding people that the competition is a click away get’s their attention.

Another advantage to starting small occurs when there is a shorter horizon for results. The sooner you can get those numbers, the better. Your example of call-center improvements is a good one. Sometimes just analyzing and revising or eliminating error/alert messages can move the needle on service levels pretty quickly.

Deep vs. Wide as you say – difficult, especially when you see so much opprotunity for involvement. The drawback to too much breadth is that you’re prevented from making all but the most cursory assessments. Later on you discover some probelms that might have been avoided if you had the time to carry your thinking to conclusions that were just a few more questions down the logic path. That doesn’t help your cause.

Promoting UX is a double-edged sword. It’s often hard to draw a direct cause/efect relationship to UX improvements and product success. Claiming a win is a little like Sherlock Holmes’ deductive reasoning mantra; eliminate everything else and what you’re left with is the answer meaning, all things being equal, if the only thing done differently was the inclusion of UX practices then that must be the reason for success. Unfortunately, that’s not usually the only thing done differently on any given engagement. That, said it’s still possible to take a bow when the numbers come in. By the same token, it’s also possible to divorce yourself from the failures which goes back to what I think is part of the real difficulty in acceptance; Accountability.

UX practioners, unlike business owners, don’t usually have P&L responsability for the products they work on making it easy to be marginalized. As Seth G. points out, it can be the person more than the practice. If you can establish yourself as a trusted advisor, you can build that influence.

I like to say that the buy-in is a process of evolution vs. revolution. You can logiaclly explain the benefits of UX to someone but the minute the heat gets turned up on a project, they run back to what they know. But, if you can foster UX involvement to a conclusion that is supported by success, people begin to get it, have faith in it and stop questioning the need for it.

Adam Polansky — Fri, 13 Jul 2007 15:40:31 GMT

To Terry’s comments. Thanks for the response. You make some good points worth remembering. Another example I like to use as an instance where business and user value clash is “on-line ads”. To a merchandising manager who gets a fat check from an advertiser there’s obviously a positive bottom-line impact but does a user care so much? Wouldn’t they love to block that ad server given half a chance?

As for the scoring – When I was a consultant, cost typically led the way. Now-a-days, as an internal IA, the desire to stay competitive or a focus on usability (especially on the tail-end of an unflattering survey or market study) often outweigh the dollars if it come down to what stays in and what gets cut. To that point I don’t agree with the absolutes that User and Business value will always be small. That may be an attribute of a particular environment.

Don’t take as writ that scoring weights should always be constrained to X1,2 & 3. If, as you’re experiencing, there’s a sort of “Built-in” weight, due to some individual slant, you can use the scoring to counter those environmental inequities. It may be cooking the books but it should be done toward levelling the playing field. That said, the process relies on a certain amount of fair play from all the stakeholders. The public nature of the effort can help engender that. Unfortunately, that won’t always be the case. If someone with enough influence is dead sure their way is the right way -all irrefutable evidence to the contrary, there’s not a lot you can do.

Maybe the piece doesn’t go far enough into how you can extend the results of the excercise. You can take a really large list of requirements and use this method for part of it or apply it to the whole thing and use it to chop up the work into iterations. You can introduce other metrics that might be mandates in your particular environment. All these things can some into play when it’s time to make the final decisions about “what comes first”.

I don’t want to put this method across as more than a way to apply that first level of characterization to a chaotic list of “Stuff” that brings the right voices to the table earlier rather than later. The real value isn’t in the number you come up with for each feature or story. It’s in the collaberative nature of doing it, the understanding it yields and the down-stream benefits of establishing a base-line that establishes the balance you want to see between business, technology and design. It’s about getting the right people to the table in the first place.

Adam Polansky — Sat, 14 Jul 2007 23:11:38 GMT

Again, these are some good considerations. Ironically, even though this process is here being proposed within the context of IA, ideally it’s managed by someone else like the Project Manager because as one of the participants, UX should be on even footing with the other stakeholders. You’re right. You don’t and shouldn’t be viewed as a list-nazi.

That said, this effort is specifically designed to temper the kinds of extremes like your example of the “splash-page=10” scenario. (For me it was about finding a graceful way to put the “interactive Rockette paperdoll” applet in the…uhm…proper perspective.)

To your point about the big picture; that’s one of those constant vigilance issues that we’ll always labor under throughout the entire life of a project. I wish I had a nickle for every time I looked up and realized that the default display of a drop-down list box had just claimed 20 minutes of my life that I’ll never get back. These days it’s become an integral part of how I operate with my teams to be the one to keep asking if we’re really keeping our eye on the ball.

Your last point brings up another item that probably should have been mentioned in the article which is that unknowns are still relevent in this process particularly where technical ease is concerned. Sometimes they just don’t know how easy/difficult, fast/time-consuming something is going to be and that’s all they can give you. However, if you can determine that there’s high user and business value, it’s enough to say “Let’s factor-in the due diligence necessary to establish the tech effort. By the same token, if the other values are low, you can probably conclude that the discovery effort isn’t required at that time.

There are TONS of similar exercises in which we’ve all taken part. Common sense dictates that you have to do something when you begin with an unqualified list of requirements. This is a mash-up. You mention design purpose and design objectives and while those concerns are the ones closest to my heart, I realized that there are other people whose business and technical objectives are just as near and dear to theirs and justifyably so.

This exercise isn’t meant to put UX in the driver’s seat. It’s meant to get UX into the balance when you’re determining how to move forward so you’ll spend less time moving backward later on.

Adam Polansky — Sat, 14 Jul 2007 23:45:49 GMT

Great interview! Chris Fahey and I were counterparts at Rare Medium and were affected by the some of the same events. That was such a great collection of talent at the time and I’m gratified that Chris & Co. salvaged some of that dynamic and thrived after the dust settled.

I also admire their willingness to take that a risk at a time when we were all feeling pretty tired and beat-up. I took my act internal and even now would have some trepedation about going back to a start-up. Behavior design’s success is a great testimony for the value of our efforts.

BTW Chris F.: Saw the Sirius Radio micro-sites…*evil snicker *.

Adam Polansky — Mon, 18 Feb 2008 23:07:46 GMT

You’ve brought up one of the symantic pitfalls that has actually come up in discussion before. Within my firm, the use of the term “quality” led to some questions about compromise. In this case, to one person, “quality” took in the perception of an application as it ’s going through acceptance testing independant of much of the dynamics we discuss here. To them, is was about a product “working as designed” regardless of what informed the definition. In this context, “Quality” simply means that the application in question must absolutely have certain capabilities or there’s no point in pursuing the project.

All the constraints in question (Time, Cost an Quality) aren’t necessarily being established – just recognized. By this I mean you’re asking hypothetically: “If we have to choose later between keeping or dropping something on the project, what will be the driver; the budget the time-frame or some assessment of the user’s need for a feature relative to our understanding/belief of the user’s goals for the application?”

You may be right that no one would want to openly opt for a sacrifice of quality in an ideological sense but the fact is that when constraints come to bear and they’re breathing down your neck, the affect of these forces is clearer and more explicit. Some things will budge; take more time, spend more money or yes, have the application do a little less. I’ve seen each circumstance in practice. This exercise is meant to apply a sense of what those pressures might be earlier rather than later when the choices, no matter how self-evident they might become, are more painful when resources and effort have possibly been poorly directed or expended. In other words: wasted work.

Adam Polansky — Thu, 19 Jul 2007 05:40:52 GMT

To Richard’s questions and comments…

One of the things that gave rise to this exercise was that during other qualification processes I’d seen (If there was one at all!) too many factors were being layered on at once and not very transparently and therefore not very evenly.

I deconstructed the process. The rating step is JUST about ratings given totally within the prejudices of the user need, biz value and technical ease by the people whose worlds revolve around those prejudices. The scoring, as I said, might be tinkered-with although I probably wouldn’t incorporate negative numbers because it literally has negative connotations. (Remember, at this stage, people are a little fragile about the things that are important to them. It’s a finesse point but an important one.) Some teams have used a 1-7 scale to get more distinction between features. As you point out; All you need to be able to say is; the relative value of “Feature A” when compared to “Feature X” is higher/lower.

Afterward, when you’re horse-trading to define the scope, you can still include a “lower value” feature based on some of the other externalities like “spec pre-approved” or “legal mandate”. An example is a “Terms and Conditions” page or text block . The user doesn’t much care, it’s easy to do technically but it doesn’t really make make or save money. It’s not going to get a great score but the legal dept says you have to display it and you’ll get sued if you don’t so guess what! It’s in!

This excercise is a little like alchemy where you take a substance, let somthing else act upon it, see the result and take the next step based on your observation. Don’t be too quick to collapse the steps. More and more, my work efforts have been helped by figuring out “What NOT to worry about” at least for the moment and convincing people that you can serve urgency better by being more patient at the beginning.

I’m really gratified that this looks like something you’d want to try and I’d love to hear how it plays out. Good luck.

Adam Polansky — Thu, 19 Jul 2007 05:41:49 GMT

One of the instances that gave rise to this in the first place was the fact that I had a boss who added suggestions to a requirements session that were way off the mark in terms of business and marketing goals not to mention cost.

I couldn’t tell the person she was….uhm…impractical. The scoring did the work for me and since the rating came from more than one domain, no one person was in the awkward position of shooting down an idea that everyone at the table (with one exception) knew was not going to happen.

Like you said though; good ideas can come from anywhere. I was on a panel discussion last night and one of my colleagues made the point that you sometimes need the input from someone who doesn’t live and breath your product all the time. They don’t know all the politics. Something either doesn’t work for them or something might make it better in their opinion.

The good thing is that you don’t have to discriminate at the gate, let it all in with a smile and let the process do its work.

Adam Polansky — Wed, 18 Jul 2007 18:31:23 GMT

Exactly Seth! That’s where the effort estimate comes in as one example of what you’ve described. And the natural cut-off I describe lets you take the features and roll them up into the kinds of things you have in your list with an aggregate value associated with them.

Yes, points are thinly veiled dollars but as you say, it helps people keep their eye on the ball.

When I was consulting and we were going through the horse-trading phase, I made it clear that if it started to look like someone wants to discuss anything having to do with contracts or rates, that’s a conversation for another table at a another time. Furthermore, by trading against these sub-totals, if you determined that you just couldn’t stay within them and meet the goals of the project, (After all, that technically sophisticated photo of the bosses wife is a deal-breaking user goal) you’ll have a clearer idea of what that conversation needs to cover.

Adam Polansky — Wed, 16 Jan 2008 20:41:18 GMT

This serves as a nice overview. Much my last year was devoted to building out our team (as you know ;)).

We looked back at some of our past hiring successes and failures and we realized two things: 1.) Like the circumstances Christina described, we were in a position where being a jack-of-all-trades was not necessary. We didn’t need everyone to be a “does-it-all-heavy-lifter”. 2.) What we did need was for everyone to have what we called the combination of proficiency and presence. Proficiency, I think, breaks down into the distinctions you provide here while presence is probably what you’ll cover in Part II.

Having difficulty finding the tried and experienced IAs (at least those we could afford), we also mined sources for people who were, as Sonya Smith-Wong used to say; “newly self-aware” IAs. These are people who have the intrinsics of presence but not necessarly all of the hard skills – you can learn Visio but do you “think” like an IA?

Looking forward to the next installment.

Adam Polansky — Wed, 27 Feb 2008 12:46:50 GMT

Great article! It’s nice to read something about Web 2.0 that isn’t passionately layered over with hype.

Chris’ point about cultural change is the thing I see as the most material factor in how successful Web 2.0 initiatives will be in the context of larger firms.

There are other considerations that come with the fact that a firm might be publicly traded or owned by an equity firm or some other body whose interest in a company is directly tied to profitability that can be forecast. Web 2.0 business plans often require the kind of “faith” that is difficult to get from an executive level that answers to a board of directors so the stakeholders begin to try and shore up the initiative in several ways.

Because of this context, the built-in tendency of companies to jump on a new idea but apply old thinking to its execution retards the outcome. It seems as though the best 2.0 applications out there have been able stay pretty targeted in their goals. Focus on core-competencies has always been a factor in business success. However, when a larger firm says “Hey kids, let’s build a Web 2.0 product”, they initially think through all the great participation they’ll invoke, the freedom of expression that will characterize it, the bazillions of dollars that will come with an integrated media model and the great extension of their brand that will occur as a result of this new Web property.

Then they get to thinking…

Participation, hmmm…we’ll need to develop a multi-channel marketing plan to create buzz and incent people to use our site.

Free expression, hmmm…can we expose ourselves and our brand to unsolicited editorial content? We’ll have to go over the fine points with Legal.

New media model hmmm…this can be done effectively but if we want to get lucrative contracts from our ad buyers, what concessions will we have to make to the look and or function of the site?

There’s also the layering-on that occurs when multiple organizations within the firm want a piece of the pie which results in cramming additional functionality or elements into the product. These stakeholder-needs start to move away from that core focus of the application.

It would be too sweeping to say that big company’s DNA creates a prohibitive environment for the development and perpetuation of a successful Web 2.0 app but I think there needs to be a degree of isolation and protection around those efforts to get them off the ground effectively.