An Audience of One: Creating Products for Very Small Workgroups

Beautiful Information

Discovering patterns in knowledge spaces

A column by Jonathan Follett
August 20, 2007

As creators of digital user experiences, we must transform complex workflows and tasks into useful applications. Experts have written much about the UX design process as it applies to broad audiences, industry-specific vertical markets, and large corporate user groups. However, as our evolving information economy continues to encourage greater and greater specialization of job roles, there is an increased need for customized applications—digital systems that only a select few people will ever use.

It’s now not only possible, but also economically feasible to produce customized digital products for smaller audiences. There are many UX practitioners—especially those within IT departments at small companies and government entities—who build applications for very small teams—even for audiences of one. And though the UX design process for the micro team or single user has many similarities to designing for larger user groups, it also has its own unique challenges. There might be a specific person or team your user interface must satisfy rather than a persona or user profile. So, no longer is your audience an abstraction, but a real person or team you must get to know and understand so well you can create a usable, elegant digital experience just for that audience of one.

Champion Advertisement
Continue Reading…

Small Organizations, Big Requirements

Small organizations feel the pressure to modernize their information systems as much as larger companies do—perhaps even more so, as they interact with and compete with bigger players who have deeper pockets. And while there are innumerable off-the-shelf software options available, sometimes a custom or semi-custom system is the best solution for them to pursue—whether it be for reasons of security, flexibility, or efficiency.

The information these systems record, track, and manipulate can be as varied as the different types of organizations themselves. A state government agency might need to manage information regarding medical processes for disability retirees. A small construction firm might need to share project files with subcontractors. A company that schedules flight time for private jets might need a better way to organize, access, and interact with its data.

While it might seem counterintuitive for a company to spend the time and money to create a custom system for a small team, the rewards can be great—providing benefits like quicker processing, real-time collaboration in the field, or reduced printing costs.

As work trends like telecommuting and virtual teams increase in popularity, organizations seek every bit of leverage and efficiency that technology can give them. It’s not surprising that running a virtual team can be extremely difficult without the proper software to enable communication.

Pressures to digitize work can also come from collaborators and partners. Larger firms sometimes refuse to work with smaller companies who can’t demonstrate they have a digital workflow. And, on the government side, state and municipal entities must answer to increasingly tech-savvy taxpayers, who demand greater efficiency for everything from records access to form processing.

Faster, Cheaper, Better Development

Over the past few years, we’ve seen advances in the tools that let development teams create customized systems—in particular the increased popularity of open source Web application frameworks such as Ruby on Rails and the availability of highly functional, low-cost toolkits for everything from file transfers to optical character recognition to image editing, which make it possible for developers to offer powerful functionality for less cost. Depending on a project’s budget, a design and development team might build a digital product from the ground up, customize an already existing open source system, or create something in between.

An Intensive Process

UX design and development for a small audience requires a process that is similarly rigorous as designing and developing a product for a larger user base—from gathering and analyzing requirements, to prototyping solutions, through testing, revision, and so on—with a few notable differences. Design cycles are almost always shorter, and the impacts of changes in prototypes and beta applications are immediately measurable, whether positive or negative. You need not wait months for usage statistics and the results of follow-up studies to start coming in; you’ll know a user didn’t like a change in the user interface when your mobile phone starts ringing five minutes after it rolled out. Because of these factors, our ability to create systems that truly serve users’ needs becomes greater, as do potential pitfalls like letting user preferences get in the way of long-term system goals.

Documenting the Current Workflow

Many small organizations have produced their data systems in a piecemeal, haphazard fashion—never looking at their information system as a working, connected whole. The result can be a patchwork of paper forms, annotations of special cases on handwritten sticky notes, white board calendars, and arcane filing systems.

If companies previously felt the need for customized applications, they likely produced them using software such as FileMaker Pro or Microsoft Access. And more often than not, someone unfamiliar with UX design principles and conventions constructed the applications, resulting in less than desirable user experiences. Such applications quickly become unwieldy as their databases grow and poor design makes information difficult to access and update.

Accurately documenting the current workflow can be the most important step in designing an application for a small team. Often, companies have never recorded their small teams’ workflows and processes, which just a few key individuals hold in their minds. In such cases, process documentation can serve not only as a tool for analyzing the workflows and identifying where best to implement digital solutions, but also to provide an informational overview for stakeholders—maybe for the first time.

Assessing Technical Requirements

Assessing technical requirements is a surprisingly tricky prospect for small teams. While there’s no need to guess the size of a person’s monitor, the type of computer system, or the speed of the Internet connection today, planning for future upgrades can be next to impossible. Small businesses and state agencies, in particular, often have patchwork computer systems; sometimes running operating systems and other software that disappeared long ago in the corporate world. And frequently, emergencies like computer or other hardware breakdowns or failures drive upgrades rather than the ongoing need for better technology. Designing your Web application, intranet application, or server-side software to run on computer configurations in such an atmosphere can be frustrating.

Immersion in the Workgroup Culture

When creating a digital experience for a very small audience, the design and development team can find it beneficial to immerse themselves in the day-to-day routines of the workgroup—not just for an initial round of contextual inquiry, but also for on-site usability testing of rapid prototypes and ongoing beta testing.

This type of perpetual, one-on-one interaction with users requires especially strong interviewing, observation, and interpersonal skills. And the relationship between the development team and the users becomes extremely close. If you have a three-to-six-month project engagement, you might very well feel you’ve become part of the group. The difference between creating a specialized digital experience for a small audience versus a more generalized experience for a larger one is similar to that between designing and building a home, working with the family that will live in it, versus constructing an apartment building where you know only general demographics about the people who will dwell in it.

Just Enough User Interface

While an off-the-shelf product might provide a quickly implemented, stable solution, users who are not technology professionals might not find it easy to work with it. For instance, 37signals Basecamp, shown in Figure 1, provides an excellent way of managing virtual teams of designers and developers. However, it’s not as good for managing people with non-technical backgrounds who—despite how easy it all seems to us—can find the product’s user interface and conventions unfamiliar and overwhelming.

Figure 1—Basecamp

It’s considered almost politically incorrect these days to mention that some people, whether by virtue of their age or working background, might not be comfortable using computers and exploiting the online world to its fullest extent. But even though there are some seniors who can code rings around the rest of us and plumbers and electricians who use PDAs and Web-based scheduling and invoicing systems, the fact remains that learning a new computer program still intimidates a good portion of the population outside the technology industry.

For small workgroups like those I’m discussing, the problem is: Organizations whose members are not intimidated by technology generally already have digital solutions for their workflow issues. So, we have to solve these problems for the remainder who have been reluctant to embrace technology.

Off-the-shelf solutions—even those built for industry-specific workflows—often have user interfaces that, even if elegant, are too complex for entry-level users and have features that are wholly unnecessary to the tasks such small workgroups need to accomplish. Paring such user interfaces down to the bare minimum of features users need is one of our most important tasks as UX designers for small audiences.

Avoiding Design Process Pitfalls

While UX design for small audiences is, in many ways, simpler than large-scale product development, it can still be a process-management challenge. In fact, controlling the process and making it work within the close quarters of a small business or government entity can be the most difficult part of this type of work.

Because there are no barriers between the users and a UX consultant, you must be absolutely clear about defining each step of the design process and its appropriate tasks. The temptation for small teams is to revisit issues—long after you’ve considered them closed. Small organization dynamics are different from those of larger organizations—they’re often less formal, with flattened hierarchies. For example, in a company of ten people, everyone might want and expect to have input into the design. And, to add another wrinkle, if you’re the designer or developer on the project, the user could very well be your employer, which can make it difficult to say no when people ask for inappropriate changes. Outlining the steps you’re embarking upon, getting buy-in at each stage, and ultimately, sticking to your plan is paramount.

It’s also vital that an outside design team understand the project and its relative importance within the company’s workflow. The danger of designing custom and semi-custom applications for a single person or a very small workgroup is that, one day, the user or users might move on to other jobs. Designers must design the final product not just for a specialized task, nor for a particular person in a role, but for a combination of the two—a difficult balance to achieve.

Once development of the new system is complete, ensuring users have adequate training on the system is an important step that development teams sometimes overlook. Providing users with Help, good documentation, and product support and making the occasional phone call to see how things are going can make a big difference in an organization’s overall satisfaction with an application.

For the UX professionals who are willing to take on the challenges of designing applications for small audiences, the process of interviewing, researching, and understanding the requirements of the user base becomes a much more intimate exercise. Such an experience not only brings valuable insights to your projects for larger organizations and audiences, but can also help you to hone your design process in a demanding environment. Ultimately, UX design for small audiences might end up being a unique area of expertise, with its own best practices and techniques. 

Principal at GoInvo

Boston, Massachusetts, USA

Jonathan FollettAt GoInvo, a healthcare design and innovation firm, Jon leads the company’s emerging technologies practice, working with clients such as Partners HealthCare, the Personal Genome Project, and Walgreens. Articles in The Atlantic, Forbes, The Huffington Post, and WIRED have featured his work. Jon has written or contributed to half a dozen non-fiction books on design, technology, and popular culture. He was the editor for O’Reilly Media’s Designing for Emerging Technologies, which came out in 2014. One of the first UX books of its kind, the work offers a glimpse into what future interactions and user experiences may be for rapidly developing technologies such as genomics, nano printers, or workforce robotics. Jon’s articles on UX and information design have been translated into Russian, Chinese, Spanish, Polish, and Portuguese. Jon has also coauthored a series of alt-culture books on UFOs and millennial madness and coauthored a science-fiction novel for young readers with New York Times bestselling author Matthew Holm, Marvin and the Moths, which Scholastic published in 2016. Jon holds a Bachelor’s degree in Advertising, with an English Minor, from Boston University.  Read More

Other Columns by Jonathan Follett

Other Articles on Design Process

New on UXmatters