Boxes and Arrows: Comments by Anders Ramsay

Anders Ramsay — Fri, 26 Jan 2007 14:52:34 GMT

Good point Adam – I was actually going to make mention of the somewhat testosterone-heavy tilt of the attendees, but then decided against it because I found that the girls were just as much in the thick of discussions and presentations as the boys. I’d say the BarCamp NYC conference had quite a bit of the retreat feel as well, at least compared to those I’ve attended.

Anders Ramsay — Mon, 26 Feb 2007 11:40:20 GMT

Very interesting article. While I think there certainly is something to be said for simulation tools, I have personal experience with several of these tools, including iRise, which I used for designing enterprise apps as an in-house IA at a multinational. First, re. the price, it does not have to be as high as 150K. Our package ran about 50K, which still is an astronomical sum (though not necessarily for a multinational or other large corp, which is a key demographic for iRise) – though packages can run up to 250k (which is what I was told Yahoo paid back in the day for an earlier version of the system.)

While iRise in many ways is very powerful, I ultimately found that it’s key value was in being able to rapidly communicate a new concept. In other words, it worked when part of the early stages of an IKIWISI (I Know It When I See It) requirements gathering model, in which a design was sort of grokked from a set of high-level business requirements, and then I just cranked out a functioning simulation in a day or two, to which stakeholders then responded. *However*, when the proof of concept phase was completed, and time came to actually get into detailed design, it turned out to be far more effective to just whiteboard stuff and return to doing wireframes (either visio or xhtml or flash or some other combination of tools) in collaboration with designers and developers. Why? Well, there are many reasons…

One huge reason was that we found prototyping the functionality in the actual target environment to ultimately be a far beneficial approach. In doing so, we were not only validating the user experience, but also validating the technology.

This is maybe an even bigger reason: at least from my experience, these simulators by and large are not capable of rapidly prototyping ajax functionality or other highly customized interaction design in which things refresh at the element level or animate or whatever, which for me, is an essential component of modern interaction design – for that reason, they may become a constraining factor, since one might only consider design options that the simulator supports.

Anders Ramsay — Fri, 21 Nov 2008 17:42:09 GMT

Ryan – protoshare looks interesting – like you said, Axure but online. My main concern with this tool as with any canned prototyping software is that it constrains you not to what the actual technology is capable of, but rather to what to the tool is capable of, which isn’t very conducive to innovation. Though I generally stay away from any kind of prototyping tool, I think protoshare could be useful for the intermediate stages of a design evolution, (i.e. after sketching, but before actually starting to build something), particularly for someone who may not have access to developers in the early stages of the design process (an unfortunate reality IMO.)

But the big problem with these tools is that they create a very sophisticated illusion of something that does not exist, meaning that while customers think everything they see will work just the way it works in the prototype, the actual experience built with real code may be very different. For that reason, it’s critical not to assume that a prototype is a validation of your idea, and that you actually have to build it to know if and how your solution really will work.

Anders Ramsay — Tue, 25 Nov 2008 20:44:55 GMT

Jonathan – re. how a prototyping tool constrains you vs letting Google inform you about an existing solution, they are definitely not the same. The constraint created by a prototyping tool is an artificial one, while existing solutions on the web are not so much a constraint but a *starting point.*

In other words, if I have an idea for a design solution, I will only be able to simulate it with a prototyping tool if whatever widget or behavior I want to use is supported by that tool. (For example, if I want to prototype drag and drop behavior, but my tool does not support that, this is an artificial constraint that has nothing to do with the real-world solution.) A Google search, however, would reveal what the latest and greatest ideas are out there relating to that idea, essentially what the state of the art is. And I might be giving Google too much credit in being able to show that, but the larger point is to simply to use the web itself to see what the limits are of what has been accomplished so far. And, more importantly, to be able to *build on those ideas* rather than being constrained by a certain prototyping technology.

Anders Ramsay — Wed, 26 Nov 2008 04:53:20 GMT

Hi Philip – Flash is great for prototyping applications, and if I were a Flash expert, I would probably sketch out design ideas in Flash no matter what the production technology, just as if I were a PowerPoint or Visio or Illustrator or Fireworks expert, I would use those tools for all my explorations. (They would be my hammer and every design problem would be a nail.) But no matter what tool you use, at some point you will have to face reality. And if you’re designing an application that will be implemented with one technology and exploring the solution with another, be it flash or whatever, you are really only sketching, only exploring, and you can keep simulating away until the cows come home and you’re still never going to have actually validated the solution.

The points you raise above seem to tell me that I may have not done such a good job of communicating a fundamental aspect of the methodology I described in the article. In the iterative development methodology, after having done some sketching and prototyping, using everything from pen and paper to Flash or whatever, you then actually *fully implement* that unit of the application. In other words, you are at that point *not* prototyping, you are actually building. Then, for later iterations, you can take the XHTML/CSS/JS production files and use them as a starting point for prototypes for other application units or updates to that unit. I’ve done this many times, and it is incredibly efficient and powerful. I realize that, particularly since the article is titled “Prototyping with…” that this may be a bit confusing. And the fact that iterative development is a completely different paradigm compared to traditional waterfall probably doesn’t help much either.

Anders Ramsay — Fri, 12 Dec 2008 16:08:57 GMT

Hi Alex – I’d definitely be interested in beta-testing this tool. You can reach me via the website listed above.

Anders Ramsay — Thu, 26 Mar 2009 22:47:57 GMT

Hey Dan,

Thanks for your comments!

Re. only being able to prototype what you are able to code, a fundamental aspect of what makes prototyping with XHTML powerful is that you no longer need to be the “Lone UX Designer” toiling away in isolation using that piece of software (i.e. Visio or Axure or OmniGraffle) that no one but UX folks uses. Instead, you can contribute one aspect of the solution, such as content structure and hierarchy in an XHTML file, while another team member, such as a front-end developer then can collaborate with you, using that same file as well as external files (e.g. JavaScript files) that they link together, to add things that they are good at, such as nifty Ajax widgets. In other words, XHTML allows us different team members to literally link together their various areas of expertise.

And if other team members aren’t immediately available to work with you on that, then my recommendation is to sketch out the key states of your nifty widget idea (either by hand or using some illustration software, whatever makes sense for your team and whatever you are fastest at), rather than spending a lot of time trying to simulate it with Axure or whatever. and then work with them on truly prototyping the idea by involving the people who actually will be building it. (More on why I don’t use Axure or similar tools at http://is.gd/p9oS )

Re. being discouraged from designing novel interactions/widgets, that, to me, is what we do during sketching/whiteboarding, at least initially. And for an idea to make it beyond the sketch level, it should have sufficient buy-in from other team members that they would be willing to invest some time in participating in creating a prototype.

Anders Ramsay — Tue, 02 Mar 2010 23:14:13 GMT

Hi Anthony – great article. At a high-level, I think you really do a great job of highlighting some of the shortcomings of Agile and the challenges of integrating User Experience Design into Agile. There is an overarching theme here of UX people trying to fit their work into an Agile model and getting really really frustrated.

I see two reasons why that is the case. First, Agile was not intended to solve the UX challenges; it was intended to solve developers challenges, which is why, as you say, there is an unclear role for design (tho’ “Design” has a different meaning in Agile.) Second, and this is a point I don’t think you make that is fundamental to this entire discussion: You talk about a typical Agile process. Let’s be very very clear: **There is no typical Agile Process** because Agile is not a process, it is a way of thinking about design, an attitude. More importantly, **Agile is a completely different paradigm compared to waterfall** – this is why UX folks keep banging their heads against the wall in frustration when trying to fit their roles into Agile. Trying to fit the role of Information Architect or Interaction Designer into an Agile team is like trying to figure out how to best put a steering wheel on a bicycle. Sure, it is possible to do it, but it will be awkward indeed, because a steering wheel was designed or an automobile paradigm and not a bicycle paradigm. This is something that is very very hard for traditional designers to get their head around. Agile replaces the idea of roles with the idea of competencies. Like a sports team, while you may generally play left field, you would not hesitate for a second to take over the center fielder role if the situation demanded it.

Re. your statement that “spending money on software development without a plan of what to build is like asking a construction crew to erect a tower with no blueprint” is a perfect example of old thinking being applied to a new paradigm and completely flies in the face of fundamental Agile thinking. The construction of a building is a *terrible* and misleading analogy for building software, which is nothing at all like physical engineering and construction. The very reason why we are stuck with a waterfall model is because the engineering model was misapplied to software. In contrast to building a physical building, in which you have standard communication notation (e.g. building codes), software has no such attributes. This is why software development plans in fact are no more than speculation. *That said* I absolutely agree with you that there is a need for some up-front planning, some big-picture design, something we at ThoughtWorks refer to as a QuickStart, with “Quick” being the operative term. In other words, it needs to be very brief and intense, and with the understanding that until you start building, you really won’t know what you’ve got. In other words, until you are building you are only speculating and proposing. It is not until you start building that you really are defining which is why I disagree 100% with the statement that Agile is good for refining, not defining.

Sorry to come off so negative. Great article overall.