Dorian: I've been a visual designer, I've been a system administrator, I've been a back-end developer, I've been a front-end developer. Databases, internationalization, security.

I've really been all over the map that is if you see where it is connecting to subcutaneously—to me it's all different facets of the same thing.

The thing that was really serious to me—the time that I'd just had it—I quit my job as a developer in 2007 and I vacillated. I was like, OK this is a question a lot of people have—do I go and get another job or do I freelance?

I was vacillating back and forth and I got advice from people like, Why can't you do both? And I'm actually beginning to believe that they are mutually exclusive, they have mutually exclusive attitudes. And going for one is the opposite of going for the other. You've got to pick one.

I ended up leaning towards consulting. And I needed to understand why. What is it that repulses me so much about the model that we do? The model that we do as designers, as developers, the acquisition of what I would call highly-synthetic artifacts. And by highly-synthetic, I mean you have to do a lot of synthesis in order to get the final result.

You have to make a thing, to make a thing, to make a thing.

So I put software and websites in there but there are other things too, like writing a novel would be highly-synthetic. Any sort of really creative endeavor like recording an album. Making a movie not so much because there is a crapload of industrial activity like building sets and what-not in there.

But there are a very set number of things for which the physical medium is not actually all that important. What's on the medium and information is on the medium—in the case of a novel, it could be an e-book, could be print—the medium doesn't matter—the physical.

And that's important because I believe that—I believe this because I have observed it, I have lived it—is that the way that we treat the acquisition of these highly-synthetic artifacts is like a construction project.

You've got a businessperson who has this chunk of capital and they are like, How do I turn this chunk of capital into a bigger chunk of capital? That is the only question they are asking, that's the only question that they care about.

So somebody comes along and is willing to accept that principle, that whole premise that we can turn your certain sized chunk of capital to a size x+n chunk of capital. That's what we call ROI.

So now we are speaking the same language.

And what ends up happening, at least in my experience, is that the risk of getting that thing done on time and on budget, is all, of course, on the part of the person doing it.

Their prize is a big hunk of money, and it's usually cut up into 2 or 3 different pieces.

And so their incentives get all out of whack, and their risk is extremely huge. And this is why we have death marches and feature bargaining and why we have all sorts of really nasty compromises that if, in my opinion, the way that we thought about it, the way that we conceived the deal, was we just changed our understanding of what it is that we are actually trying to deliver and what we are trying to conceptualize and what we are trying to do: the service and the product that we are actually trying to make.

If we took a look at that from the level of finance, from the actual level of business, there might be something in there that would make it possible to make greater, better products that didn't compromise.

I understand compromise, it's a calculus of what you can work with. And if you push one value up, another value shrinks and another one juts out in another dimension.

I get it, I've lived it, I've been there.

But what is really depressing is the compromise that you have to make that is like so bad that it actually obviates the entire purpose of why it was that you were doing whatever it was that you were trying to do. And it turns into.. you are like, we just have a perfunctory result: we need to show something.

That kind of interaction, I really want to make that obsolete. I want to make that idea as something that you just don't do because it's nonsense..

The magic word to tell a lawyer is nonsense.. So that's just an aside.

Lara: What's the solution?

Dorian: So the solution? As it pertains to the web, I think apps are a little bit harder and other things are a little bit sketchier.

Going back to Charles Dickens who wrote serials and got feedback in the interstices between them, and his stories would meander all over the place because of the feedback that he was getting from his readers. Like, I don't like what that character is doing. Make them do something else.

I'm not a huge Dickens scholar but I understand that much.

The solution as it pertains exclusively to the web—and that's the only thing I've really been looking at—is we look at it as a medium. We actually look at the—I hate to say the technical affordances because they are more like the conceptual affordances of the medium.

We are dealing in websites where we probably should be dealing in discrete business processes and user goals. We should probably be dealing in discrete pieces of content.

And that does not correspond one to one to the page. It could be an inset, it could be several pages, but the idea of like, we do wireframes for the homepage, and then we fill out the sections, and then we go and pester the client for content. And then it's on us to make sure that this all happens on time.

I find that pathetically inexcusable. I find that that is completely lacking of any spine. It might be harsh but any understanding of the medium that people are working in. It has entirely different affordances, like the fact that you can just replace stuff.

There are technical constraints. But I believe that those technical constraints have been conceived under the assumption of the business constraints.

Lara: You were talking about the discrete user needs. I think so many companies come to us when we're doing freelance work and they say, replace this or just make it look better.

I think in the business world, it's kind of talking in that language. So how do you help them uncover those discrete user needs?

Dorian: I think just to continue on the notion of what the goal is, a lot of the time people say we need to redesign the website and they call it the site redesign.

The implementation is considered the end product and the goal. And just some of the things that I'm doing with my clients is I'm actually changing the objective to say that the implementation is not the goal. The goal is understanding the users so that when you have a widget on the implementation, you can actually trace back the provenance of why that thing was put there in the first place all the way back to the persona and the initial research.

And the thesis there is that a design criterion or a set of abstract ideas around why things should be the way they are can outlive any implementation and if that is good enough, then that is actually better than the implementation.

But you need an implementation.

But what if we imagined that the implementation, like the programming platform, language, or whatever you use was disposable, and that the design artifacts were so good—and of course there is a lot of feedback on this, this is not a one way process. But the design artifacts mature to the point over time that they are so good that you can, if you felt like it, just go and change that piece of discrete business process from one implementation to a completely different one—and not upset anything in the process.

If you could do that, you would have a lot more freedom, I think, from vendors—which is one of the things that we cared about, we care about not getting locked into vendors. Because we sort of believe what if we based our relationships, our business relationships, on mutual value rather than dependency.

It was a very difficult thing to articulate with this one client, what the priorities are. And it was like, we don't want to get screwed. That was the major motivation.

I think a lot of entities have this problem: they have somebody they go and hire, and they ask a certain set of questions like how much is it going to cost? and how long is it going to take?

As long as there is somebody who is willing to answer that, they are going to get the same kind of result: the site launches and a lot of its features—and most of them were cut which is another thing—The remaining, surviving features kind of go thud.

Some of them might and some of them might not or whatever. But the features of the site.. because the information that created them was considered to be of less importance than the implementation. But what if we considered those as being more important?

Imagine you can have a persona that lasts 20 or 30 years, why wouldn't it? As long as that constituent exists in your business, there is no reason why you would shred those when you have your PHP doo-dads—you have your Drupal site. We can put that in the shredder because we don't need these personas and wireframes and flow diagrams anymore because we have the implementation now. So thanks designers, bye! And I don't see how that is a smart idea.

Lara: Yeah, the personas should be consistent over the years.

And I think that it's our job to educate corporations and so when you are presenting some of those abstract ideas to change objectives, you are also educating them at the same time.

Dorian: And that's sort of why I've been starting to talk in CFO language. When I start talking about stuff like risk because risk makes the bio-feedback ears pop up. The risk of the construction project.. when you look at it from an ROI-centric construction project style perspective is I try to look at risk as a 3D object, where.. what they call a tensor, which is a 3 dimensional vector or whatever..

You have three dimensions in risk. You've got probability, the likelihood that the risk is going to happen. And a risk can be positive as well. The risk of winning the lottery for example.

And you have the magnitude which is the size of the lottery ticket, the size of the prize. And then you have the horizon.

And this is a new one to me because at first I was just using those two.

The third one was, when the risk stops being a risk, when it goes away, it doesn't matter anymore. So getting your product out by Christmas for example. Well after Christmas it doesn't matter. Or say catching an airplane, it's the same sort of idea, like if you miss the airplane it doesn't matter.

In that framework, we can kind of imagine when we push and pull on one we get a different shape.

So it's like what if we think about changing the shape of the risk involved in acquiring these artifacts? What does that look like? You look at the affordances of the web and what it afford? It affords these little pieces.

What if we said instead of a lottery ticket that looked like it had a very, very expensive cost.. And relative to cost, it had a very low return. And it wasn't measured in multipliers it was measured in percent.

In the horizon, the duration or the period where the risk is still a risk, is a really long period. You are locking up your capital a year or two years or whatever. And you can't do anything with it. It's an all or nothing excursion.

And what if we took that and stuck it in a blender—is really the idea—and we changed it so that instead of one big monolithic risk, we change it to a bunch of little tiny risks. So the equivalent to pull tabs but hopefully with better expected value.. The cost is low, relative to the cost of the ticket, the value of the prize is extremely high, not measured in multipliers but measured in exponents.

And the probability is arbitrary. We actually can't measure it and we aren't even going to try because the amount of effort required to figure out just how likely this was going to happen…

It's what Nassim Taleb says: Don't even bother forecasting. And he also says for example, Take your portfolio, put 80% of it in the most boring bonds that you can find. Take the other 20% and put it in the sketchiest stuff that you can find.

So what I'm saying is: hack 80% of what you expected to pay off this, let's look at that 20% and then we hack that up as well into little pieces that have potentially exponential returns—arbitrarily high—we have no idea how high they will be but we know the downside is fixed.

In the construction model, the upside is fixed. ROI has a fixed upside. It's also a fixed downside but it's a fixed upside too.

If we figured out a way to actually bring the last mile to the ground because right now it's sort of like a helium balloon up floating.. So if we could tether this idea to the ground, we might actually be able to.. specifically again websites because they are so easy to bash up like that.

We might be able to invent an entirely new methodology.

Lara: Are you saying that if someone says come redesign my website, you possibly present.. again looking at the objective but still maybe scaling down the project and only look at certain parts that might have a hard impact?

Dorian: The only way that I know how to do this so far is to stop thinking about it—and this is something that I have yet to talk to actual business people about—but stop thinking about it like it is a capital allocation. Think of it instead like a rate. It's a burn rate. You change it from a capital expense to an operating expense.

That rate is fixed. And so over the course of the year, you only spend a certain amount of money. So your downside is bounded. So you can't lose arbitrarily large amounts of money, which is what the CFO wants to hear.

So rather than thinking about it as a redesign as well, the way that I'm actually doing this, the way that I've implemented it, I made some very specific technical interventions that's kind of like putting up a scaffold.

You set up the server, or bank of servers, depending on the size of the site. And what they do is they go in front of the existing server.

I should probably provide you with a diagram. It's actually in a piece in Contents Magazine called No Longer No Sense of an Ending.

Lara: We'll put a link on it.

Dorian: And there is another one called Dissolving the Redesign.

You put these servers in front of your site or a server, let's make it simple.. You've got a small to medium website and it only needs one hosting account or whatever and it's not some crazy clouded CDN monstrosity. It's just a little modest website.

So you put this thing in front of it. And what it does is it first of all creates a space to put new stuff. And if you put something at the URL on the new one, it serves out the new one. If there is nothing there on the new one, it passes through to the old one.

It's as simple as that, it took me an afternoon to write this thing and it's called a reverse proxy. That's a very technical term and the idea is it just sits in between the user and the origin and mediates, and it's conditional so that if you stick something in the way, that's what it sends out.

That was the first intervention.

The next intervention was trying to figure out how do you look at the template. So we took a strategy of effectively sponging off or bleaching off the header, the side bars, the footer, and just leaving the little nugget of content in the middle. And that was what was corresponding to the site.

I'm super over-simplifying this stuff and are probably going to get a lot of listeners saying, how the hell do you know how to do that? What about this thing you left out. I'm leaving out a bunch of stuff right now.

The basic idea is not only do we bleach the content coming through the old server, we stick in back on in a template system that actually runs below the application layer, completely.

That way we can manipulate things like the navigation because that becomes its own resource—you can just hack on that. We can manipulate the—we can actually change the look of the site even though I would never recommend that to anybody. But we could change the look to the site without actually changing any of the back-end.

We aren't even touching it. We are scraping off all the stuff and we are sticking it all back on again.

As we create these discrete user goals, as we create these discrete pieces of content, they start to occlude the original site. They start to get in the way of it, and once there is nothing left—once every single piece has been patched over and covered up—then we go back to the template and we make a pretty new one and then we launch because the reality is that a lot of the actual material functionality of the site could've been running, having people using it for months. But we just re-skin it with something pretty and now we've theoretically launched the site even though you've been using this thing for a while.

What we are doing is we are actually demoting the launch from something.. either demoting or promoting, depending on how you want to look at it. But we are demoting it from being this nail-biting affair of like, Do we throw the switch or what? To like, It is like a PR complete smoke and mirrors of all we are doing is changing the look of it. And the functionality is running..

Wouldn't that be nice to live in that world where that is the norm? When all that stuff is covered up, you cut it loose and then you take off the scaffolding. And now you have a completely new website.

It's also handy for when you've got a hairball like we do at the IA Institute, we've got a hairball of back-end platforms.. We have WordPress here, Drupal there, Movable Type over there. We have some SaaS monstrosity, some platform hosted thing.

We've got all of these things, I counted 13.

Like how do you sever those relationships? How do you kill that vendor? How do you get rid of that?

You have to make it not matter. And that was the impetus for this I guess at the beginning.

Lara: That's good. I think it really helps take the fear out of looking at something so big and putting it into small pieces like you said.. But replacing those a little at a time so that when you do, just add that visual layer, then it looks like to everyone that it's a new site but yet everything else is running really smoothly. All of the other components are already solid.

Dorian: Correct. And we do use the word component, except it has a very specific meaning. It has a meaning borrowed from graph theory in mathematics. A component in a directed graph is something that is closed.

So you can imagine that every dot or every box in the graph is a page or a resource of some kind. And the arrows are links in between those resources.. not necessarily just links, they could be embeds as well.. They could be an image or something like that. Or an inset, you embed an inset.

It's closed though: it doesn't have arrows going out of it. And that's a diagram.. If you have a diagram where you make this thing, it has a terminal condition at the end and it goes to the final node and then it's done.

That is the exact equivalent to a discrete business process.

You can make that and you can install it and deploy it, and have your users use it, and the turnaround time on that, we aren't talking about months but we are talking days.. possibly hours.

I mean the idea of this would be that you'd get so much useful information about the kinds of things that you need to do.. And not only that but it's also the decomposition of its anatomy and how that all works that you don't prioritize as a first order activity anymore. You prioritize because there is this thing sticking out and it's obvious that that is the right next thing to do.

And you know that it's going to have value.

So it's not an issue of how do we bargain features—and I'm totally ripping this from Alan Cooper—you try to make it obvious that we've got the information that we need and if we change the job into making the next step obvious, then we aren't going to have this sort of disconnect of: We are the experts, you should do it this way.

If you have ever actually looked at the problem of task prioritization from a computational perspective, it's NP-complete. Which means you have to use heuristics. Which means that you aren't going to get the same result twice because if you try to do an exhaustive result, it would take you so long to figure that out, that there would be no value in it—is basically the issue.

And of course if you added one more item, then you would explode the overhead exponentially and you'd have to do it all over again except that much more work.

So let's not do that.

With task prioritization, the reason why we care about it when we do requirements analysis—once we've done that, we prioritize.

There was a really good book written in 1964, it was a PhD thesis by Christopher Alexander who was getting his PhD in math I believe at the time, and he said something really profound about design. And that is, Two arbitrary designers are not going to believe that a given misfit [he calls it], a given thing that needs to be dealt with, has the same importance. But they will all agree on whether or not it is valid. But they aren't going to agree on whether or not it's important and whether or not it's a priority.

So there are techniques for saying, rather than trying to mitigate the amount of requirements, why don't we just blow them all up and make the—and this is kind of what I'm getting off into the weeds because we had some conversations about this.. Jorge Arango is really interested in this, Andrew Hinton is really interested in this:

We'd blow up the requirements and we'd say throw in hundreds of requirements, and what we're going to do is we're going to stitch them all together, the relationships with each other, and how they either correlate with each other or they conflict with each other.

And then what we are going to do is forget all about whether or not they are important because we are never going to agree on what's more important.

What we do is we decompose the structure, we pull the structure apart mathematically so that we get these little islands of sub-problems. So we get little bits of requirements here and there.

When we've got that, they become more manageable and then we can subdivide them further.

And then that little thing that you thought was either not worth doing or maybe it was your pet thing that you thought was really, really important. When you do that, you actually sub-divide the problem to the point where these little things of arbitrary importance become irrelevant because the problem is so damn small. And if the problem is small, and it's obvious what the solution is, you just solve it and you ship it. And even if it's something silly like the favicon on iainstitute.org.

I was like, Wow that's blurry and doesn't look good. I know, I'll open up Photoshop and I'll make a little pixel art one that is clear and looks better.

That took me 10 minutes. It was obvious to do. I didn't need clearance for it because I happen to be a director of that organization. So I didn't ask anybody's permission, it was completely unilateral, I just did it. Because it bothered me. It was obvious what to do and I just did it.

So what I want to do is I want to pulverize these problems into something that you can do obviously, you can care of as an obvious thing.

And then also set up the infrastructure so that if somebody has—and I know there are legal issues and there are issues of who owns what turf and so on and so forth. That I'm going to hand-wave away because it doesn't need to be the processes as totally cavalier as making a new favicon because I'm authorized and I felt like it.

It can be a little bit more rigorous than that.

But it doesn't have to be paralyzed, I guess, by the complexity, and it also doesn't have to be artificially simplified because it's that process of artificial simplification that degrades the value of the product.

What makes a good product is people actually solving problems, not looking like they have solved problems.

So let's explore the idea that the construction project is not the only way to acquire this stuff because there's tons.

Lara: That's great. That's a great wrap up.

Dorian: Thank you for having me.