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.

Planning for Pixel Perfection & Mastering the Art of the Meticulous

High-quality, professional design is instantly recognizable. Every pixel is in place, every font considered, every interface element carefully selected, every color chosen intentionally. The end result glows with quality and effortless clarity.

Perfection not only thrills and pleases the client, but makes the entire design process easier on you, the designer. By getting the presentation and polish right from the beginning, clients more easily trust you, don’t second guess your choices ( or at least, not as much), and are far more likely to engage your services again.  The principle of least astonishment applies here;  try to think of the behavior that will least surprise someone who sees your work. The higher the quality of your deliverables, the more effortlessly they will be accepted.

But how do you get there? How does a junior UX designer develop an eye for detail and the skills to produce professional work? I remember struggling to climb this seemingly unobtainable pinnacle of perfect design many years ago, and today, I work with junior designers wrestling with the same challenges. This blog post came out of email discussions within our team, and we decided to share it publicly.  I realized recently that telling our designers they need to be perfect is useless guidance, and even somewhat cruel to ask of them. But offering some guidelines about how to get to perfection might actually be useful, to our internal designers and perhaps a larger audience as well.

When discussing how to teach perfection in design, we came up with three basic principles to keep in mind: Consistency, Accuracy and Coherence. Let’s look at each one a bit more deeply.


Interaction design must be consistent on many levels. Navigation and element placement must be consistent throughout all screens. Colors and other visual touches must remain the same or within the same palette and visual family. Language, tone, labels and word choice must work together to create a unified voice. For example, if a header uses a blue background, stretchy width, a subtle grid pattern and is 120 pixels high on some pages, it should use the same styling on all screens.

The “flip book technique” (quickly moving between pages when reviewing your work) really helps with consistency. You can see where things shift out of place, etc. Consistency can also really help with accuracy, but more about that below.


Ever been in a review meeting where the client gets fixated on a typo? Nothing more annoying, right? It is up to the designer to always make sure files are absolutely accurate, spelling has been checked, the right logo is in place, and every bit of client feedback has been considered and properly reflected in the screens. Accuracy moves beyond just pixels and words to also encompass interaction design. It includes making sure all user behaviors have been thought through and reflect what can be done on the intended delivery platform within any technical limitations. Accuracy also means being aware of common interaction design platform conventions and respecting them.


Coherence is making sure the story, the big picture, makes sense. In coherent design files, numbers add up, the narrative holds together and the interaction model reflects actual usage. Coherence is also what separates great interaction design from graphic design. A coherent interaction model is absolutely essential for users – if you don’t create a coherent mental model first, your users don’t stand a chance of making sense of your work.

The less time you have to spend on consistency and accuracy, the more time you have left to focus on crafting a coherent narrative that thoroughly addresses user needs. This is the heart of UX, and when you can achieve true coherence in UX design, you start to internalize what it means to be a senior designer.

Methods & Techniques

Ok, enough of the high level abstract approach. What does a junior designer actually DO to ensure flawless deliverables? Part of the answer is simply to check your work, again and again, and then have someone else check it as well. There is no magic trick here, only a lot of hard work, and most importantly, developing habits that become second nature over time. As your work matures, you will find yourself spending less time fidgeting with alignment and size issues, and more time thinking about the interaction model, your users’ needs, and how the approach to the application design as a whole could better meet those needs.

But first, it can sometimes take junior designers a long period of time to master consistency and accuracy. This is my personal approach to create perfect files for client delivery. In general, it seems to really help to export to the format you will be using to deliver to the client. Also, printing screens out and reviewing them in analog is often quite useful, though I have to counter-balance my hatred of wasting paper with the pay off of a non-glare surface. I also review any notes from the client or myself a few times too, to make sure all requested changes got made and didn’t get lost in the shuffle. Finally, I take a look at the previous rev of my files, to find any elements that might have disappeared by accident.

Then I send off my files to another member of the team for a review with a fresh set of eyes. I take and incorporate the feedback from this review, double and triple check the files a last time, and finally send them off for client review.

Sound like a lot of work? It is! But so worth it. When quality is lacking, client dialogue devolves into pixel picking and bickering over details. The big picture gets lost and the project as a whole loses its way. In our experience, doing many multiple rounds of review first is the only approach for professional quality design work.

User Stories, Scenarios & Use Cases

What’s the difference? Are they the same? Why do I even care?


When designing and developing software and sites, I hear these three terms – user stories, scenarios and use cases –  employed all the time, often interchangeably. While I am not intending to issue a didactic nomenclature smack-down (how tedious!), some definition and clarity can’t hurt. Most importantly, when people are working together on a project team and trying to create and agree to any of these three kinds of deliverables, consensus goes a long way.

In general, all three terms represent ways that application teams try to define and understand what the app will do from the user perspective. User stories, scenarios and use cases can therefore be understood as framing devices; they provide mechanisms to understand and plan technology development around the end user, instead of focusing development and product features around the constraints of the business, the platform or the underlying development languages and libraries.

The exact purpose and audience for each term varies. Scenarios are generally used by user research people to communicate with design teams. User stories are written largely by project/product managers as part of definition and requirements documentation . The audience for use cases  is primarily developers who need to write test cases and need to understand if their data objects are handling the appropriate i/o, errors, and exceptions.

Now let’s examine all three terms and associated deliverables as well as processes more in depth.


Let’s start with scenarios. They are usually tied to personas and are part of creating a story about who the user of a particular technology is, what they want, what they know. A  scenario is therefore usually written in narrative form, perhaps with pictures and illustrations as well. Scenarios are generally written at the beginning of a project during discovery and requirements gathering phases. They provide human-centered anchors to guide design and development by providing tangible faces, names and stories for how technology will be used.

A common generic format for scenarios goes something like this:

User Stories

Now what about user stories? User stories are generally used by Agile development teams. They are meant to replace long complex documentation with short sentences that capture the essence of a user need. They are intentionally short and granular – each story captures just one task or action. User stories are defined during development before or at the beginning of each sprint.

User stories are generally written in this kind of syntax:

Use Cases

Finally, let’s describe use cases. Use cases are generally written as part of detailed product requirement documentation. They capture the goal of an action, the trigger event that starts a process, and then describe each step of the process including inputs, outputs, errors and exceptions. Use cases are often written in the form of an actor or user performing an action followed by the expected system response and alternative outcomes.

Use cases tend to employ this kind of format and content:

Still confused? Maybe a more tangible real-life example will help ….


Josh is a 30 something mid-level manager for an ad agency, metro-sexual and beer aficionado. He likes to try new and exotic beers in trendy locations. He also enjoys using a variety of social apps on his smart phone. He reads a review  on Yelp of a new burger & beer joint downtown with over 100 beers on tap, and decides to go walk over after work and check it out.

User Story:

A user must wants to find a bar, drink a beer.

Use Case:

Customer walks to the restaurant
Customer enters the restaurant
Customer finds a seat at the bar
Customer scans the menu
Customer selects a beer
Customer orders selected beer
Bartender takes order
Bartender pours beer
Bartender delivers beer
User drinks beer
User pays for beer

In Summary

Use cases, stories and scenarios are not interchangeable terms – each defines a specific process and set of deliverables. That said, there are no hard and fast rules. It makes sense to review the needs of your project, what stage of development you are in,  the skills and familiarity levels of the team, and then choose the user and task definition process that will work best for you.

Links & More Info

This is a good example of a well written user scenario
is often over-looked in user scenarios, but not in this excellent example
This pdf includes more definition for user scenarios as well as an example
Here is Wikipedia’s take on scenarios

Here is a good summation article about user stories
Good examples and instructions for writing great user stories
You can buy a whole book about writing great user stories
of course has an overview page as well about user stories
How to write user stories using cards

Wikipedia has a good definition of use cases
And here is a good example of a use case about using an ATM
A good article on forming good use cases
Another longer article on writing use cases (with stick figures!)
A travel related set of use cases
A very usable template for use cases

Do you disagree with my definitions? Have more clarification or obfuscation to add? Please comment below or send me email!

Book Review: Thoughts on Interaction Design

Most books on designs tend to be focused on how to do stuff, what to make, and what deliverables should be. I have read a lot of excellent practical books along these lines.

Jon Kolko’s Thoughts on Interaction Design takes a very different and quite enjoyable approach. This is a book explicitly for Thinkers, not Makers. It is a book about semiotics and phenomenology; the meaning of language and the creation of desire. Kolko and his co-writers take a step back to think deeply about why we design, and what design can and should be.

This book also tackles the difficult and mostly unexplored questions of what is design, and how does it fit in the world of technology and software development. If design is ultimately about people, how does it work in an engineering process? The writers strongly encourage designers to embrace their roles as problem solvers, master communicators and thought leaders.

Reading this book ultimately renewed my sense that design is about more than making meaningly tasks slightly easier to perform or convincing consumers to buy more crap. At its very best, Design is about making the world a better place.

4.5 stars

Best read over a glass of wine in a contemplative state

Low-Fidelity vs High-Fidelity Wireframes

Wireframes are a basic part of the application or site design process. They allow the interaction designer to quickly sketch out screen layouts without delving into the niceties of visual design. Wireframes are generally considered blueprints – they define structure, size and layout without proscribing any decorative details such as colors and fonts.

However, all wireframes are not the same. In fact, the variety of types of wireframes is almost as varied as the number of designers making them. There is no fixed recipe for successful wireframing, but generally a distinction is made between low-fidelity and high-fidelity wireframe diagrams.

Low Fidelity Wireframes – A Minimalist Start

Low Fidelity wireframes are generally a very simple place to start design. They attempt to define navigation, framework and basic structure. They are often produced in tools like Balsamiq for an intentionally hand-drawn and informal look. Low fidelity wireframes are useful for starting conversations, deciding very basic functionality as well as navigation layout. These simple sketches are NOT as useful for showing actual interactions, the weighting of elements on a page or paper prototype testing.

Here are some examples of low-fidelity Balsamiq wireframes:

Example 1: A wiki
Example 2: An iPhone app
Example 3: A video player

High Fidelity Wireframes – Designing for the Details

High-Fidelity wireframes fill in the details missing in their simpler predecessors. They define the weighting and visual hierarchy of the page, actual form and interaction elements, and often labels, instructional text and some copy. They can be used in sequence to show how a specific task can be accomplished in a sequence of screens. High fidelity wireframes should always aspire to defining all product and interaction details. They should provide a clear enough visualization of an application or site to allow developers and the engineering team to begin their work.

High-fidelity wireframes are usually drawn in tools such as OmniGraffle (Mac), Visio (Windows) or Adobe Illustrator.

Here are a few examples of high-fidelity wireframes:

Example 1: an enterprise application
Example 2 : a video service
Example 3: an online newspaper