October 2011

Viewing posts from October , 2011

Running a Distributed Design Agency: a One Year Retrospective

the outdoor home office

the outdoor home office

Almost exactly a year ago, my partner Jason and I decided to start an agency. This is not an odd or unusual decision for designers with over a decade of experience like ourselves. But we chose to do things a little differently. Instead of renting a shiny office space and hiring some full time employees, we chose to start a distributed virtual agency. What does that mean? It means we have no permanent office and no full-time employees. We have a website and some cloud-based apps that tie us together. It is not how the world traditionally imagines an agency, but to be honest, we feel this model works much better.

It’s been an awesome adventure, at times a rather wild ride, and after a full year of this experiment, I wanted to give an extremely subjective report of how it went and what’s next.

Why Did We Do It?

As designers, we often found it quite difficult to be successful as employees within enormous corporations. I have to admit, I find it humorous that many companies want to emulate Steve Job’s success, but then they decide the best way to do it is to hire a bunch of designers … at the bottom of the corporate hierarchy. Without the power to truly drive product design decisions (and that includes the schedule, the feature set, and at times the means for implementation), designers are so often set up to fail within typical technology corporations. So even though Jason and I had many wonderful colleagues brimming with talent, experience, and skill at the big companies where we worked, we did not feel we were doing meaningful, successful and well-designed work that shipped and succeeded in meeting user needs.

As consultants however, we tend to be hired “outside the system.” Consultants and agencies are usually brought in to fix something that isn’t working and/or provide expertise that has been recognized as missing within a team or company. This means we start from a position of strength and respect. Furthermore, as outside agents, we are hired for a specific task or project, not as amorphous employee objects to be assigned and re-assigned wherever management sees fit. This kind of defined scope for consultant gigs certainly helps with the success of design and designers.

Jason and I had both also worked extensively as independent consultants, but we both ran into limitations of trying to be a one person team. As individuals, we could not provide all the interaction design, visual design, front-end development and/or research that our clients typically wanted within the time-frame required. Therefore, bringing in other folks to round out our skill set made perfect sense.

But why a distributed agency you may ask? Why not a typical brick and mortar agency in downtown San Francisco, or somewhere similarly schmancy? We thought about the traditional office model, I have to admit, but in the end we decided that the advantages of the distributed model far outweighed the traditional approach. So, let’s look at the benefits of our model for our clients, for our consultants, and for us.

Benefits for our Clients

The biggest benefit for our clients of our distributed model is super flexible teams. Does this project need a researcher or three researchers? Does it need a project manager at all or can we skip that? Is front-end development going to be handled by the client or the agency? These questions vary of course from project to project. So instead of forcing clients to accept some predefined team and process that an agency is tied to, we can be super-flexible and just assign the people needed. This leads to much more streamlined, efficient and successful projects, every time.

We also can pull talent from anywhere, regardless of geography. If there isn’t a stellar logo designer available physically in the same geographic area, no matter. We have hired designers in Belgium, Germany, Ireland, and the Ukraine. The entire world is truly our only limit.

Last, but in no way least, we can offer lower prices for the same work done by traditional agencies. The math is simple. Our overhead is lower, and we pass on those savings to our clients.

Advantages for our Consultants

The biggest win for our consultants is work/life balance. Our people are free to work where they like, how they like and for the most part, when they like. They can choose their projects, and they can define their own schedules. For designers, this is huge. Morning folks and night owls can work as suits them best. People with kids can work around school schedules. Vacations, hobbies, events and other personal pursuits can all be accommodated. And if there is one thing I know for sure, happy designers are far better designers.

By allowing our consultants to set their own schedule and determine their own work environment, we allow designers to set themselves up for getting into the flow and staying there as long as they need to.

I have found that for the most part, most designers tend to introspection and long hours of solitary work. It’s not that we designers aren’t collaborative, it’s just that there is a lot of pixel pushing and hard thought that goes on between the bouts of collaboration, and cube farms are generally not good for this kind of concentration. So allowing designers to work from their own studios almost always produces a higher caliber of results as well.

Finally, consultants make more money. There’s that, enough said.

The Wins for Us

Now the advantages for us as a distributed agency are quite simple and derivative of the advantages for our clients and consultants. We have very low overhead, and we can be super flexible and pivot our business on a dime. If we decide, for example, to ratchet down our services business and focus on building our own software products, no problem! If we want to scale up or down in volume, it’s easy!

Without a full-time staff and office rent, we can evolve, grow and change with our personal goals and also the ever-changing nature of working in technology. We can also easily experiment with different kinds of clients, projects and processes without making huge and costly commitments. Quite frankly, considering the speed with which technology changes here in Silicon Valley, I do believe the flexible agile model for agencies is only going to grow in popularity over the next decade.

The Future

So what is next for Cloudforest Design and our merry band of creatives? A one-year milestone is a great time for this kind of introspection, and I have been thinking a lot about our future. Our biggest goal is to find more awesome clients that we can really help. This year we have gone far in figuring out the kinds of companies and projects where we work best, and now the challenge is to find more of them. We are also thinking hard about how to attract and keep more of the awesome design talent we have been honored to work with this year.

We are also beginning to consider branching out into our own software products and educational products as well. There is an overwhelming imbalance between the massive number of developers and paucity of designers in the world, and that is not going to change soon. So how do we educate more people of all backgrounds to become better design thinkers? What educational materials, classes, ebooks and blog posts can we provide to increase the general design awareness and sensibilities in the technology sector? Are new tools needed to improve communication and management in projects that span design, engineering, and product teams? These are the questions and challenges we hope to tackle in the upcoming year.

Designing for Complexity

“Everything should be made as simple as possible, but not simpler.” – Albert Einstein

Simplicity is a frequent mantra for designers, and even a perpetual goal. How often have we heard or said – make it clean, make it simple, increase the white space, decrease the clutter. To be sure, simplicity is an utterly worthy goal in most cases.

But life, well, life is infinitely complicated, and sometimes software systems are complex as well. A to-do app on a smart phone should be super simple, but I want the security management tools used by the IT staff at my bank to be complete, providing them with the means to do all they need to do efficiently and without error. Sometimes, complexity can not be easily hidden, abstracted away or shoved under the hood. So what does a well intentioned designer do when faced with the challenges of designing for a complex system?

When confronted with a situation where there is a need to provide expert users with detailed information or an ability to manage very complex tasks that require years of experience or large amounts of training to master, I would like to suggest this is an appropriate time to shift the overriding design principle in play from “simple” to “efficient”, or even, “adept”. Instead of trying to hide or downplay the complexity of a system, instead, navigate users through the system with frictionless ease towards deep mastery. Humans are capable of incredibly arcane and recondite tasks, when trained properly and presented with repeatable and familiar guidance along the way. Therefore, UX design does not need to always shy away from complexity, but rather, sometimes must embrace and build for it.

Let’s look at some examples of truly elaborate and intricate software systems, and then explore some design strategies for coping with the complex.

Examples of Complex Applications

Here are examples of two major areas of software application design that are deeply complex in nature and truly call for more elaborate interfaces and design solutions; logistics and also remote monitoring and control.


Applications that manage as well as provide workflow control, oversight and reporting for logistics and operations are rarely simple. Think of all the details that rest behind a simple act like ordering a physical book on Amazon. Is it in stock? Which warehouse is most cost effective to ship from? How does it get picked, packed, labeled and shipped? How does this single book purchase weigh into the massive reporting structures behind Amazon accounting?

Inventory management is just one example of a logistics application. Supply chain management and shipping are other related examples. And if thinking through the purchase of a single book seems complex, imagine the supply chain management applications that track every single part and supplier for a car, or a smart phone.

Remote Monitoring and Control

Software to oversee, monitor, maintain and control complex systems from afar are another seriously intricate and involved design challenge. Examples of this type of application would be the infamous systems used for air traffic control as well as train and subway control. I have never seen the software that manages the New York subway system, but it is easy to imagine its detailed demands as well as the possibly life imperiling consequences of thoughtless design choices.

Distributed database and network management tools are another common sub-species of this software category. Not only can a database or network schema involve thousands of objects and nodes, the virtual nature of these objects just adds another layer of abstraction to test and stretch the human brain. The database clusters that run the New York Stock Exchange are one example of the natural extreme of what software can create and manage for mankind, and they never will be simple.

UX Strategies for Complex Systems

So, let’s look at six basic strategies, techniques and approaches for taking these complex systems and turning them into manageable software designs.

1. Prioritize Tasks

Most enterprise software packages can do hundreds or even thousands of tasks, but not all of theses tasks are equally important or frequent.Therefore, going through an exercise to prioritize use cases can be extremely helpful. Once a designer knows what tasks are most common versus least common, it is far easier to make UI prioritization decisions such as choosing what actions are triggered by big buttons instead of small text links, or what items are in the main navigation versus secondary or tertiary navigation.

This exercise is known as weighting. Weighting allows the human brain to easily identify the most important controls in an application easily. Unweighted applications can be visually overwhelming, whereas weighting and prioritization guide users to their most common destinations effortlessly.

Segmentation is another corollary to weighting. By grouping tasks around a common theme or object, users will naturally seek and find related controls. Logical groupings can be around objects, or around common workflows. For example, users, groups, roles and permissions are almost always grouped together.

Of course, weighting and segmentation do nothing to help manage complexity if they aren’t approached from the perspective of the personas representing your heaviest users. If you weight your tasks according to the feature bullet points on your product’s sales presentations, or segment tasks according to your organization’s org chart, users will feel the functionality they rely on to do their jobs has been buried.

2. Be Consistent and Use Patterns

Humans just love patterns. We are hardwired to do the same things in the same way repeatedly. We look for objects in the physical world to stay where they were last put, and we expect the same of our software. Therefore, keeping navigation, language and page placement consistent across an application is key. If a command says Start Server on one page and is shown by a big green button, the same language and visual treatment should be used everywhere consistently. Similarly, if a link to My Account is shown on the top right of some screens, it should consistently keep the same placement across all screens.

Patterns are another similar technique to appeal to familiarity and recognizable controls. One of the more common patterns known to many users is the use of a wizard to guide users through a multi-step process. Most everyone will recognize a wizard, know that the numbered steps represent parts to the process, and will have a clear sense of where they are and what needs to be done. When patterns emerge as part of your product, it makes sense to use these patterns consistently, to both reinforce and satisfy user expectations about their behavior. This consistency can provide the user with the confidence that the time and energy they invest in mastery will be rewarded.

3. Use Data Visualizations (wisely)

Data visualizations are all the rage and for good reason – there is nothing like a basic line graph to make a trend immediately obvious from what would otherwise be an indistinguishable sea of numbers.  Charts and graphs are absolutely invaluable for parsing large data sets and getting at underlying anomalies, trends, totals, comparisons and proportions. When used properly, data visualization can be used to tell a story, alert users to errors and oddities as well as call out recurring events and issues.

The key is to keep data visualization relevant and accurate, with an appropriate level of fidelity and user control. The choice of which data to visualize and of the data visualization method should be appropriate to the user’s task as it relates to the data. Extraneous charts or chart types (whether to provide eye candy or other spurious motivations) only serve to clutter and detract from the clarity of the data message the expert user needs to be able to receive in a timely and efficient manner.

That being said, it is equally important to provide a sufficient level of granularity and user control to allow the user to complete their task. If the user needs be able to see daily values, showing them a chart that only contains monthly values isn’t going to help the user much with their task. Some tasks require the ability to apply complex filters and rules to reveal patterns or associations that would otherwise be difficult to detect. In order to choose these mechanisms wisely, it is of the utmost important to have a crystal clear understanding of the nature of the user’s tasks, particularly those of the frequent/heavy/expert user.

4. Adapt UI to Roles

Most complex software is designed for not just one type of user, but several. For example, the domain administrator who sets up a process for source control management to be used throughout an entire company is not the developer who will be checking in code. Personas to the rescue! By carefully identifying the different types of users in a system (personas or roles), and the tasks they are required to perform, large chunks of the application can be “hidden” from those users who will never need them.

Adapting the user interface to the role of the user and their specific needs requires a fair amount of careful planning up front, but it can be a huge aid in removing superfluous commands and complexity from the user’s experience.

5. Learn and Adapt to Repeated User Behavior

Software systems are too often designed as static. What you get out of the box, is what you get, forever. However, it is not hard to see after a week or month, what tools and controls are used by individuals most often. A set of user-specific frequent tasks on the home or dashboard of an application is a quick way to provide short cuts for each user to what they need and do most often. More sophisticated UIs can change the weighting and priority in navigation and screens layouts to match user behavior as well. Similarly, forms or entries that are re-used frequently, and with the same common values, can be pre-filled based on previous repeated entries. Here the concept of software memory comes into play to help the user gracefully complete repeated tasks as effortlessly as possible.

Adaptive UIs require an understanding of the way a user’s task may change or evolve over time. Day one tasks are different from month one tasks, and those may different yet again from month two tasks.

6. The Simplest UI is no UI

Sometimes, the best user experience solution is to skip the user interface entirely. It is always worth asking if a UI is the right solution for a problem, or if instead a script, a notification, and/or a wiki page of instructions might be the better answer.

Strange as it may seem conceptually, sometimes the answer might not be great design, but great DevOps.  DevOps is about collaboration, people over process over tools. Taking it even a step further, NoOps is about automation; invisible tools that make people and process unnecessary. Whether NoOps turns out to be a pipe dream or not, it’s clear that in many areas of software development and operations, there is a strong push towards automation as a means of increasing software quality. A desire for automation leads to the need to eliminate user interfaces that cannot be easily scripted and ultimately controlled by other software.

Never send a human in to do a computer’s job.

In Conclusion

This simple toolset of methods to mitigate complexity is by no means exhaustive, but should provide a good starting point when designing for complexity.

If nothing else, remember that complexity is not always enemy and need not be equated with difficulty. Complexity is merely another design constraint. Complex applications can be immensely powerful and even aesthetically pleasing and enjoyable to use when designed with the proper approach and techniques.