Designing for Limited Resources

“Good online experience design must accommodate real-world limitations.”

“It is not difficult to manufacture expensive fine furniture. Just spend the money and let the customers pay. To manufacture beautiful, durable furniture at low prices is not so easy.”

—From the IKEA website

In information architecture circles, we often talk about “good design” and “effective user experience” as if they can only exist in a world with no limitations—with unlimited time and money, free reign over technology, and an army of people to administrate the finished system. This, however, is rarely the world in which we work.

And this focus on the ideal is not true of most other design disciplines. In product design, for instance, limitations such as cost or materials are almost always a key factor. IKEA, the international retailer beloved for its low-cost, durable furniture, frequently states that the company “designs the price tag first.” This is not just hype. IKEA explores untraditional manufacturing options (candleholders are made in fuse factories or by the manufacturers of laboratory test tubes) to find unusual ways to build products that meet very specific limitations: products that are low cost, highly durable, and that can be shipped flat.

In the same way, good online experience design must accommodate real-world limitations. From a purely practical perspective, this approach ensures that the system can be built and supported effectively. I have also found, though, that it is quite liberating to stop striving for some imaginary ideal design, and to strive instead for the best user experience that can be achieved with the available resources. In this mindset, limitations become creative challenges rather than frustrating barriers to the “right” design.

Even in an ideal world, designs must optimize both the user experience and the business return. When resources are limited, the design must be optimized to make the best use of all resources as well. To account for this complexity, it is important to have a clear understanding of both sides of the design equation?what you have to work with and what you are trying to build.

Understanding your limitations

As some great philosopher should have said, understanding your limitations is the key to designing for them. Outlining the possibilities allows you to design and prioritize accordingly. This sounds obvious, but I have found that it is frequently difficult to get a handle on just what is possible and what is not.

It is worth the effort to list out and define the project limitations early in the process. There isn?t much money? Okay, exactly how much is there? We can?t make any changes to the navigation? Okay, what counts as a change? What if the majority of users don?t notice the change in a user test? Documenting the limitations makes it much easier to see where there is room to explore, and where there is no wiggle room at all.

Some developmental limitations to look out for on any project:

• Time and money
  The old favorites. Although difficult, it is worth trying to quantity what is meant by “no budget” or “spend as little as possible.” I have seen these phrases mean anything from tens of thousands of dollars to literally no money at all.
• Existing technology
  It is rare for a project to have free reign of technical choices. Organizations may either have existing hardware and software or standards for hardware and software that may constrain what can be used. Try to understand what the limitations mean from a functional perspective.
• User expectations
  If you are working on a system that is already in use, there may be significant limitations on what can be changed without baffling your users.
• Development team
  Significant budget restrictions can mean building a system with semi-qualified resources?people learning on-the-job, client staff members, or volunteers. If you understand the skills that are available to the project, you can tailor the design and the level of complexity to the strengths of your team.
• Hardware and software
  Some designs dictate specific hardware or software decisions. If there is no budget for new purchases, you may need to tailor the design to the products that are already on hand.

These developmental limitations will affect the core decisions that will need to be made for the project: What should the scope of the project be? And, can we include functionalities that rely on a specific technology? As discussed below, these limitations should be balanced against project needs to determine a useful solution

Long-term impacts

In addition to the limitations on system development, it is important to consider limitations that affect the long-term use and support of the system. It is easy to overlook these types of constraints, as they tend to be farther downstream from the system design process, but they are no less important.

Some long-term limitations to consider:

• Deployment costs
  Distributing the system to user desktops may require an additional investment. It is important to weigh this investment against the time and cost required to make the system easier to deploy.
• Training and user support costs
  The system will not be effective unless everyone involved?both administrators and front-end users?know how to use it. Training and user support can be a significant portion of the development effort and should be weighed against resources needed to create easier-to-use functionalities.
• Time and expertise to administrate
  All systems will need to be monitored and many will need constant updates. It is critical to consider the ease of administration when designing. Unless the administrators are tech-savvy, the development effort needed for administration tools (such as content management systems or reports) can rival the effort needed to develop the front end.
• Infrastructure
  The methods used to host and support your system can impose significant costs and limitations. For instance, hosting a website on a shared public server can be cheap, but often limits your software options. Maintaining servers and databases in-house allows more flexibility, but can be expensive.
• Other ongoing costs
  Many services that decrease development or administration costs (such as application service providers, licensed content, or the like) incur monthly or other ongoing costs that should be factored into the budget.

These long-term limitations can have as significant an impact on your design as the developmental limitations. If it is infeasible, for example, to train hundreds of end users, it may be necessary to design an extremely self-explanatory system. Or, the necessity of hosting a site cheaply may rule out the use of a sophisticated packaged content management system. Your design needs to accommodate these limitations.

Guerilla requirement definition

In order to design a system that makes optimal use of limited resources, it is important to brainstorm “out-of-the-box” options. Judging whether unusual options meet business and user needs requires a sophisticated understanding of these needs?one that is both specific and flexible.

There are many classic techniques that can be used to robustly define these needs, including contextual inquiry, personas, scenarios, prototypes and the like. Any of these techniques will work for our purposes; anything that lets the team judge whether a solution fulfills the needs will work to also judge the more unusual options of a limited resource project.

Unfortunately, however, designing for limited resources often means designing with limited resources. Over the years, I have come up with some shortcuts that allow useful requirement definition when there is limited time or money. None of these shortcuts are ideal, but they often allow a bit of consideration on projects which would otherwise just skip over requirement definition altogether.

• Focus on goals
  Even if I can?t find time or budget for anything else, I will work with the organization to define and prioritize what they are specifically trying to achieve with the system. And if I can?t do any user research, I will work with the organization to define the users? goals. Without these steps it is impossible to judge whether system options will meet anyone?s needs.
• Phone interviews
  User research techniques can easily get caught up in logistics. I like phone interviews because they provide rich information about user expectations and processes, but are easy to plan and schedule. I try to do at least three half-hour interviews per target audience. While I find individual interview notes quite useful down the road, if I am really strapped for time I will do the interviews back to back and write up a bullet-pointed overview for all of them at once. Given a list of potential interviewees, it is possible to plan, conduct, and write up phone interviews for one target audience in less than four hours.
• Group interviews/ Focus groups
  If a number of users are in one location, it can save a substantial amount of time to interview two to four users at once. This certainly will not provide the same depth of information as talking to each person individually, but may provide a bit more creative input when one user sparks a thought in another. The technique is a bit riskier than individual interviews, as there is the possibility of a dominant user hijacking the conversation.
• Stakeholder workshop(s)
  With the goals defined and user research completed, stakeholder workshops can be a powerful and quick way to understand the features that your stakeholders expect. I often do one workshop to brainstorm features, and another where we discuss some sort of documentation or options to crystallize our group vision. These sessions provide a solid base from which to define both the core needs and the nice-to-have features.

With a firm grasp on these sides, you can creatively weigh options to design a system that optimizes all the factors.

Weighing your options

By this point, we have defined both limitations and requirements. In a typical system process, the next steps would be to document the vision for the project, assign priorities and complexities to features, and figure out what features should be included in the next phase.

However, in a situation where resources are very limited, I find that it is often useful to add a step at this point: Brainstorm overall structure and technology options at a very high level. These are the type of options that define what the project is and are frequently assumed rather than discussed. Does it have to be a website? Could it be an Excel spreadsheet? A mailing list? What is the core structure? Can we buy something rather than build from scratch? The answers to these high-level questions affect the approach to the features under discussion, so it is important to settle these overall technical approaches before documenting the vision or prioritizing features.

I find it very valuable to brainstorm these high-level options with a group (with at least a few people with significant technology experience). The options worth considering will obviously depend on the project, but a couple of high-level questions can be useful to consider:

• Can the goals be met through a simpler technology? Or no technology?
  For an organization with little money or technical expertise, goals might be met as well or better with unsophisticated (but practical) tools like email, Excel, or paper. For instance, monthly updates could be provided via an email mailing list rather than requiring a website to be frequently maintained.
• Can we use a packaged solution or an application service provider?
  For common functionalities (like searching, registration, or contact management), using packaged tools for at least pieces of the system, can utilize resources better than building from scratch. For instance, ASPs like Atomz or SpiderLine provide in-site search features at an infinitesimal fraction of what it would take to build this functionality.
• Can we template it?
  Designing a system where many pages are structured identically can support a lot of content while minimizing administration. Content can be either pulled from a database or hand coded into the structure provided by the templates.
• Can we make use of standard designs?
  It is possible to pull detailed designs and even open-source code for common functionalities, if you are willing to work within generally accepted standards. With shopping carts, for instance, if you refrain from re-inventing the wheel, you can leverage many readily available resources.

Once you have generated a list of possible options, you can weigh the options against one another. Put them into a spreadsheet and rate them on all the important limitation considerations for your project (i.e., cost, ease of administration, ease of training, etc.).

One of the main advantages of this approach is that you can rationally weigh the tradeoffs of each option. For instance, you might consider saving development time and cost by asking your (quite savvy) administrative team to do site updates in Dreamweaver instead of using a content management system. This will require more time from your administrators, and more skilled administration resources, but might make sense on the right project.

Creative tradeoff management can be the key to designing a system that can be built, but careless ones can often lead to disaster (i.e., We will ask my nephew to build the customer relationship management system from scratch, and host it in his basement—and then it will be free!). As you consider your options side-by-side, one will likely emerge as the right answer for your particular situation.

And on with the process?

At this point, the process for a limited resources project matches up again with a typical information architecture process. The weighing process ensures that the overall system vision optimally uses the available resources, and you can turn to more familiar issues of defining scope, considering structure, and creating the detailed design. While it is important to keep your limitations in mind throughout the entire design process (the project needs to be very straightforward to build or to administrate, for instance), I?ve found that this process is a more familiar one of ensuring the system meets its defined goals.

As the weighing process has defined an overall sense of system structure and functions, you can now create vision documentation to ensure that everyone is on the same page. You can consider complexities and priorities to determine what can be included for the next release. As for the rest—sitemaps, wireframes and interaction diagrams—I have, unfortunately, found no shortcuts.

It is our job as functional designers to design websites and systems that can be built and supported by our clients—within their resources. It is not as easy as it would be if we had access to unlimited resources, but it can be a much more interesting challenge.

• IKEA vision as stated on their website
  http://www.ikea.com/about_ikea/our_vision/better.asp

Laura S. Quinn is a technology strategy and information architecture consultant for both corporate and nonprofit clients. Her company, Alder Consulting, specializes in helping nonprofits build powerful internet and database systems with the resources they have (learn more about Alder Consulting at www.alderconsulting.com). In her spare time, Laura prepares for a new career as a homesteader with faithful practice in cooking, gardening, sewing, and weaving.