Designing for Limited Resources

Written by: Laura S. Quinn

“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.

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.

Defining Feature Sets Through Prototyping

Written by: Laura S. Quinn
The Vision Prototype allows the user-centered vision to be seen—and discussed—by all team members.Over the last couple of years, a standard method for user-centered interaction design has begun to emerge. First, you gather background from the clients and stakeholders, conduct user research, and look at competitive sites. Then you build personas and scenarios, do workshops, and conduct brainstorming sessions. All of that is analyzed down into a grand vision of what should be built.

But what happens after that? Most of the literature in this area assumes that once the designer has a vision in mind, it’s time to move straight into sitemaps and wireframes and the rest of the business of functional design. But I’ve never seen it actually work that way. In my experience, there are always clients who need to approve the vision, scope that needs to be defined, and project managers who want detailed and concrete functional requirements from which to manage. If I’m not involved, they’ll do it without me, often leaving me with a scope and a set of requirements that doesn’t have much to do with the vision with which I started.

To address this issue, over the years I’ve put together a method to translate a conceptual vision into a set of concrete functional requirements, by way of what I call a Vision Prototype. The Vision Prototype allows the user-centered vision to be seen—and discussed—by all team members. Because the prototype serves as an explicit visual representation of the project’s needs, it can be easily translated into a set of functional requirements.

What is a vision?
This method assumes that a vision has already been defined in someone’s mind, using one of several user-centered interaction design techniques (see “For More Information” below). The vision doesn’t need to be extremely detailed, but it should answer these basic questions:

  • What’s the purpose of the site?
  • What are the main things the users will do with the site?
  • What’s the general conceptual structure?

Let’s look at an example of a high-level vision. Let’s say I’m building a website that allows Quinn Exhibition, an imaginary trade show company, to sell booth space online. In my—fictitious—user research, I observed that the floor plan for the exhibition was critical in everyone’s thought process in determining everything from number of booths to the position of a competitor’s booth. Typically, sales reps fax annotated floor plans to potential purchasers and buyers show them to their bosses.

Based on this data (and backed up by my fictitious competitor research, personas, scenarios, and workshops), my vision for the website is to use a visual floor plan as a key interface metaphor. Potential clients can see what booths are available and where booths are located by perusing a familiar floor plan format. They should be able to buy straight from the floor plan.

Documenting the vision
It’s not easy to jump from a vision in your head to a list of concrete functional requirements, and it’s not desirable, for a number of reasons. At the most basic level, creating formal documentation of a vision ensures that a vision does in fact exist. While this sounds obvious, it’s a problem that I’ve seen frequently, especially in more traditional software development processes. It’s easy to build a requirements document by piecing together what everyone says they want without any overarching idea of where the system as a whole is going. Needless to say, this often results in sites that are less than cohesive.

A visual representation also makes the vision tangible and understandable to clients, users, and the rest of the project team. This makes it possible to get feedback in this early phase and serves as a touch-point for the rest of the project. When scope creep begins, it’s possible to say “Is that feature really important to what we’ve defined?”—with some assurance that others on the team will share your view of what was decided.

This is where the prototype comes in. I’ve had great success in documenting an ideal vision with a conceptual prototype which, in anywhere from four to ten linked pages, shows the high-level functionality and conceptual structure of the site. I’ve found that this type of Vision Prototype is both easy to create and easy to understand.

The prototype is built not to show the interface, the page flow, or the fields, but to represent an ideal feature set that makes the vision happen. For instance, I’ll often represent site functionality with a number of significantly labeled buttons (i.e., “Add New Location” or “Advanced Search”). These buttons serve as functionality shorthand—there’s no need to show an Advanced Search page in the prototype if the team will understand what a button labeled “Advanced Search” implies.

Because the prototype is primarily documenting an intended (or ideal) feature set, I carefully determine the right level of detail and functional feasibility. I try to represent the site functionality to just the necessary level of detail to allow an engineer to estimate the approximate time and money needed to create each feature. This means representing some specifics (especially for a more unusual feature), but certainly not every field on every page. I also go to some effort to ensure that the prototype feature set is ”blue sky” enough to be inspiring without being completely infeasible for the time and money. I generally think of the prototype as representing the feature set of the site two or three phases down the road.

The illustration shows two pages—a Floor Plan and a Booth Detail page—out of a Vision Prototype for the example website. The pages use both an interface-like structure and suggestive buttons (“Search All Available Booths,” “Split this Booth into Two”) to show the feature set. The prototype would include a few pages in addition to this: an overview or homepage, a static content template (to show that the content links are just pages of text), and perhaps the Buy Booth page itself.

When scope creep begins, it’s possible to say “Is that feature really important to what we’ve defined?”—with some assurance that others on the team will share your view of what was decided.A prototype this early? Are you nuts?
It’s worth pausing here to acknowledge that the idea of building a prototype before even defining scope alarms many reasonable and experienced interaction designers. I’ve heard two different but related arguments as to why it’s a bad idea:

  • Argument 1: Functional requirements by definition should talk about needs and specifically avoid any consideration of design like conceptual structure or specific features. Something as tangible as a prototype should come after the definition of requirements, to ensure that all the issues and parameters are considered before jumping to a design solution.
  • Argument 2: Clients aren’t able to separate a conceptual prototype from an interface design or a live website. They’ll focus on the wrong details (like the page flow or graphic design), fixate on a particular detail that will turn out to be infeasible, or just generally misunderstand the intent of the prototype.

Both of these arguments are rooted in the same premise that it’s preferable to first work at a fairly abstract level to define the scope and needs of the project before looking at a visual representation that might start to limit the field of design possibilities or encourage people to determine how things should be implemented as opposed to solely what the system should do.

While this premise makes sense in an ideal world, I believe that it simply doesn’t work in the vast majority of project situations. Information architects are comfortable working in the realm of abstract functionality (that’s one reason why we’re hired), but clients generally are not. In the same way that we wouldn’t show a user a text list of features and expect to get good data about the usefulness of the system, we can’t expect a client to be able to adequately give feedback on a high-level description of functionality.

By creating a visual representation of the project vision early, we give up a little to get a lot. We give up tight control of precisely what the client will be thinking about at each phase of the project. This can sometimes result in early discussions about things, such as page flow or graphic design, that are unrelated to the decisions at hand (by the way, I’ve seen this type of thing get somewhat irritating on a project, but I’ve never seen it cause any lasting harm). But by giving this up we gain a huge advantage: we gain the active understanding, participation and buy-in of our clients. Ultimately, ensuring our clients can effectively understand, review, and discuss important project concepts will result in better products and fewer problematic misunderstandings down the road.

Does it have to be a prototype?
That being said, a Vision Prototype may not be appropriate for every project. I’ve found that a prototype is particularly good at representing highly complex functional sites. For this type of site, it can represent a lot of complexity in a format that makes it easy to review and understand. In addition, prototypes are familiar to the many companies who already use them as a standard to get buy-in on a project.

For smaller projects, however, I’ve found that it’s difficult to build a conceptual prototype without detailing every field, simply because there’s not that much to say about the site vision. A prototype also may not effectively handle the structural issues of a content intensive site. For this type of site, the prototype can be replaced by anything that’s tangible, non-technical, and fairly comprehensive—perhaps a content map, a comprehensive set of scenarios, or a page flow (when there’s not a lot of complexity in the page flow itself).

Verifying and getting buy-in on the vision
One of the main reasons to create a Vision Prototype is to allow the rest of the project team and the client to understand, review, and provide feedback on the vision. Because the prototype makes the ideas under discussion visible and concrete, it’s common for new needs or concerns to come up at this point—even in areas that might have been completely covered in previous conversations. It’s simply hard for many people to think abstractly about the same things that are made obvious by the prototype.

User focus groups can also be useful at this point. A successful vision will generally get a “Of course, how else would you do it?” response, with some suggestions for minor additional features. Confusion, lots of questions, or lots of suggestions for major new features are all signs that the vision does not correspond with the users’ expectations and model of the system, and needs to be reconsidered.

At this point we resolve any issues, and ensure that the whole team is happy with the prototype before moving forward. In this way, the prototype becomes the documentation of the entire team’s vision.

Creating a functional requirements document
Because the Vision Prototype contains a comprehensive look at ideal functionality, iterated and approved, it is itself a representation of the functional requirements. In order to translate these ideas into a more traditional document, one can simply systematically write down the functionality shown on each page. It’s also important to think through any administrative or tangential features (user administration, for instance).

For instance, looking at the Quinn Exhibition prototype, I can pull the following functional requirements (among others) from the Floor Plan page:

  • The position of each booth is displayed on a visual floor plan.
  • All hall infrastructure is displayed on the floor plan.
  • The status of a booth (occupied or available) is displayed on the floor plan.
  • Booth details, such as the size and the occupant, can be easily seen on or linked to the floor plan.
  • The user can search for a booth based on key booth criteria.
  • An administrator can define the hall infrastructure and initial booth layout for an exhibition.

Note that there’s a great deal of work left to do to completely define the functionality. What criteria can be used to perform a booth search? How does the administrator define the original floor plan? The point of this functional requirements document is not to completely design the site or define all business rules, but to establish the functionality to the point that the site can be estimated.

I put each requirement on a separate line in an Excel spreadsheet, and prioritize each based on my user research findings and client priorities. I generally use Core, High, Medium, and Low. Core requirements are ones that the site wouldn’t make any sense without—in the example site, for instance, “The position of each booth is displayed on a visual floor plan” is a core requirement. The technical team also assigns a complexity (High, Medium, and Low) to each requirement.

The actual writing of requirements takes a little practice to ensure they’re at a useful level of detail and are relatively unambiguous.

Defining scope
The last step in defining a feature set is determining what set of the functional requirements can be implemented in the next phase. I start by working with the development team to determine approximately how much time and money will be left over after achieving just the “Core” priority features. If the time and money can’t accommodate even the “Core” requirements then there’s a problem, and we need to revisit the vision. This is why it’s important not to make the original vision too ”blue sky.”

We then spend several hours as a team going through the rest of the requirements and creating a draft scope. Features are quickly reviewed and separated in to those that should obviously be included (such as High Priority/Low Complexity requirements) and those that obviously shouldn’t (Low Priority/High Complexity). Most of the discussion is around the High Priority/High Complexity and Medium Priority/Medium Complexity features and determining what can be included to create the best mix of basic functionality and strategic features. Determining a scope is more of an art than a science, as the features tend to be dependent on each other in complicated ways. Once there is a draft scope, a more detailed estimate can be made. Often there is too much for our schedule and budget and we have to go back to determine what else can be removed.

Unless the client is very detail-oriented and very close to the team, I’ve found it nearly impossible to involve them directly in the creation of the draft scope. There’s simply too much detail and too many time and money sensitivities. Once we’re internally comfortable with the scope, we can summarize it and present it. While the client almost always has changes, it’s fairly straightforward to iterate the scope because the team internally understands the trade-offs and complexities.

All the previous steps set up a framework in which to consider the issues, generally making the actual definition of scope fairly straightforward. The development and iteration of the Vision Prototype allows the whole team—both the internal team and the client—to solidify a team vision and working relationship. Scope definition, which can often be a painful process of wrangling over favorite features, is made much more straightforward by the imposition of a common vision.

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.