The Paradox of Experience

There are some really great properties on the internet. Apple, Google, Facebook, Instagram, YouTube, Pinterest, Twitter, and many other sites do a great job of creating an excellent user experience. It also happens that these are the websites and applications most used by members of the general public.

For the average internet user, the understanding of what is possible is informed largely by experience. This presents a challenge for a web designer or developer eventually hired to create something for one of these users. How do we deliver on client expectations when the project budget is a fraction the size of the monthly (or even daily) budget of a company like Facebook, which informs the experience of that client.  

This is the paradox of experience. A client wants a great website or web application, but their reference for great is framed by billion dollar properties. At Lift, we've been through this process a few times. Here are some of the things that we've found helpful.

The Internet is Magic

Most web users would tell you that there is "code" underlying a website or application. You could replace the word "code" with "magic" and it would still be just as clear. If asked to describe how code works,  many would not be able to come up with a meaningful explanation. If a client feels like what we do is magic, our job is to de-mystify that. How can we expect them to ever understand the complexity of web features if it is all simply “magic”? We need to break down features in ways that make sense and convey the inner workings without having to understand every little detail.

Let’s use the metaphor of a vehicle. If you showed a car to someone who had never seen a motorized vehicle before, they would likely assume that too was “magic”. We know of course that under the hood is a motor, it runs on some form of fuel, is connected to a transmission, which transfers the power from the motor to the wheels, causing them to turn and move the vehicle forward or back. You don’t need to know how internal combustion works to understand the basic principles of motor vehicles and to realize that it’s not magic.

The same is true of web features. Underlying every feature is a set of code, a set of instructions, that let the program know that a certain input (fuel) triggers action (power transfer) to create a resulting output (motion). The web isn't magic, but it is complex. Clients are smart, so if we do our job, they will get it. They won’t be able to write the code, or even read it, but they will understand that what’s happening isn’t magic. They will also appreciate that they learned through the course of their project.

Confirm client expectations

Let's imagine a short conversation.

Client: "Let's just do it the way that 'such-and-such billion dollar company' did it."

Strategist: "Are you crazy, don't you know how many developers Facebook has working on things all the time?"

OR

Developer: "Do you realize how complex Instagram's photo filters are?"

OR

Designer: "That's ridiculous, there's no way that we can deliver that on the budget we've been given for this project."

It's not exactly accurate, but situations not too far from this happen all the time. We jump to conclusions. We assume the client knows what we know, we assume that we know exactly what the client is asking for, and sometimes we assume that a client is trying to get more than they paid for. These are almost always wrong assumptions.

When it comes to building on the web, it's important to clarify what a client is expecting when they talk about any given feature. Ensure that you're talking about the same feature before deciding on the difficulty of achieving that. In many cases a client’s perception of a feature is very different from the reality of the underlying complexity.

For example, when a client says "I think our site should have search like Google", what does that really mean. It is likely the client has little understanding of the complexity of Google's search algorithm (does anyone?). Instead of stating that it's ridiculous to try and implement a search like Google, unpack that. Does search make sense in the context of the site or application? If the answer is yes, dig deeper, determine what the actual use case for search would be. Complex, faceted search may be a big task and require further discussion, particularly if search was not a considered part of the initial project scope. On the other hand, a simple content based search, that returns a basic list of articles containing a specified keyword, could be much more simple.

Focus on goals

There need to be goals at the centre of any web project. User goals, those things that we want a user to be able to accomplish using the website, AND business / organization goals, the outcomes for success that we want the website to contribute to. One of the best ways to keep features from blowing up is by relating them back to these goals.

At different points in a project, it's easy for a particular feature to seem important, even when it may not be. It may just be something that a someone on the project saw somewhere else and really liked. As a strategic partner, the web developer's job is to detail why a feature doesn't make sense. It's much easier to do this if you can show that implementing a feature (especially an expensive feature, which is out of scope) won't help in accomplishing user or business goals.

Similarly, it can be tempting to think that every feature should be developed to the most refined version that can be conceived. When this happens, the whole product becomes less important that individual components, resulting in bloated features that may not be contributing to a greater end result. This not only causes projects to go over budget, but can also result in delivery that detracts from the overarching goals rather than helping to meet them. Instead, when the temptation comes to over develop a feature, take a step back and look at the whole project and examine whether putting additional effort into that feature will make the goals easier to reach. If it won’t, develop to a level of functionality that is good and save time and effort for other elements down the road.

There will certainly be times that a feature or idea comes up which isn't in the scope of the project, but DOES make sense and should be added. Relating it back to the goals makes the situation easier to deal with. When we tell a client something is out of scope without presenting options,, it's easy to see why they may get frustrated. Instead, if we can say that it’s out of scope, but we think it does add real value to your project and by adding $X to the budget, we can implement that feature, it becomes much more palatable. Of course this requires having a clear scope established early in the project.

Breakdown features

Web projects, particularly more complex projects, are invariably hard to scope out prior to project start. As the project progresses, new ideas are uncovered, understanding of features changes, and expectations that weren't clear become better defined. The project management triangle shows the interaction between scope, cost and timeline. We understand that any change to one of the three attributes MUST affect the others. That means that new ideas or adjusted expectations can be scary.

In many instances, particularly where benefit of increased budget can't be directly related to better achievement of goals, the cost corner is the least flexible of the three. There's good news though, when it comes to the web, most features can be developed to varying degree without negatively impacting the quality of the whole product.

This means it's critical to outline the client's expected features list during the discovery and planning phase of a project. We then take that feature list and create a breakdown of how each feature can be accomplished within the budget (and timeline) available. We also work to connect each feature back to one of the project goals. Being pragmatic about what's realistic, is very important to maintaining the integrity of the triangle. If everything is important, nothing is important.

Along with understanding the level that a feature will be developed to, it can be helpful to explore other options for features in looking towards the future. Just remember that exercises in "exploring" feature possibilities, without framing the potential impact to cost and time, can result in client's expectations being raised to a level that you can't meet without changing the cost of the project. If the client hasn't been prepared to increase budget, extend timelines, or both, all parties are likely to end up in an unhappy situation.

Manage the Paradox

When we go into a project understanding that the client's experience is informed by amazing things, we are setting ourselves up for a better outcome. Start off by discussing web experience and get an understanding of where the client is coming from. Uncover their favourite apps, features and functions outside of the project, then inform the approach to the scope and feature list of the project to align with their experience.