Archive for the ‘Business’ Category

We’re Looking for a JS Developer

Tuesday, May 10th, 2011

We’re looking for a JavaScript developer to join us in our Plano, Texas office on a special project. This contract position will require strong JS skills and expertise with developing for mobile environments.

If you fit the bill and want to work with our professionals and with sane work hours, hit us up via the contact form at UnitInteractive.com.

We Welcome Ryan Downie to Unit Interactive

Tuesday, May 3rd, 2011

Ryan Downie
As of yesterday, we’ve welcomed Ryan Downie to the Unit team! Ryan has done some really nice work in a short time and we’re thrilled that he’s now working with us. We’ll all be getting good use of IM and Skype, as Ryan is in Lancaster, England and most of us are here in Texas. International, baby.

Of late, Ryan has been freelancing and he’s a past and current contributor to .net magazine (latest piece is forthcoming). Aside from good taste and an intuitive design sense, Ryan brings some strong ExpressionEngine and front-end development skills. We’re looking forward to doing some great work together.

Published: Interference

Monday, February 7th, 2011

We’re happy to announce the publication of the second volume in the Curations Series! Interference is a collection of cautionary tales for design professionals. It examines ideas and conventions common to our profession that work to detract from or diminish the quality of our client relationships, policy decisions, and project practices.

Interference Cover

Taken from the writings of the Unit Interactive staff, this collection of essays is a plainspoken, no-nonsense guide to eliminating destructive traditions and fuzzy logic. Like the first volume in the series, this one deals with both overarching standards and day-to-day issues.

See the Curations Series.

Wanna Work at Unit?

Thursday, September 9th, 2010

We’re looking for another designer to join our team. If you’re currently in the Plano / Dallas, Texas area or would consider moving here and think that Unit Interactive is right for you—and that you’re right for us—we should probably have a chat.

If you want to learn more and drop us a line, visit our info & contact page. We look forward to hearing from you.

 

So, you want to work at Unit?

White Labeling Unify

Tuesday, August 17th, 2010

The current model for most web applications gives us a trade-off: free with explicit product branding, or paid with the ability to have your way with the branding. This leads us to believe that there is some actual monetary cost to allowing a change of brand. There isn’t. So what do you get for your money? At best, you get permission to at best confuse or at worst, permission to rip-off your client. This is not creating value. This is snake oil, and at Unit we refuse to take part in this charade.

Justification, Disassembled

There is one very simple reason to not allow white labeling for Unify: any branding change would alter the code, and we cannot properly support our product once the source code has been changed. Beyond this, I would like to put a finer point on our position. The following are some of the common reasons that people use to justify white labeling, each rebutted by our philosophical perspectives behind Unify.

Doomsday Scenario: “My clients will get confused! They need their brand at the top of an app.”

This morning I hit snooze on my Seiko alarm, ate some Kashi cereal,  drove to work in my Jeep, woke up my lazy iMac and posted this to the blog using WordPress. At no moment did I get confused… at least not about the brands I was using. (Thanks to David Airey for his similar progression in Logo Design Love).

Brands are not built to confuse. In fact, they clarify. A brand is a promise between the producer and the customer. Over time it is reinforced by good experiences and destroyed by bad ones. It is an honest face: recognizable and persistent. White labeling masks that face, and what do you consider the intentions of man behind a mask?

With Unify, we are building a brand through consistency and upkeep, and removing the brand would nullify any responsibility we take for our product. Marketing efforts, customer support, twitter chatter, blog posts on updates and improvements; all would be nullified by this obfuscation. This cost is too high to negate all of these efforts in the hopes of not confusing people who are smart enough – and familiar enough with brands – not to get lost.

The Appeal to Revenue: “You can charge tons more for a white label license! I will pay it!”

The only person who “pays” when costs go up is the end-client. The problem is, as explained above, THEY see no benefit. The only person who benefits from white-labeling is the middleman. The go-between gets to represent someone else’s work as their own, and the client pays a premium. How is this fair?

We have crafted a price and a model for Unify that correctly reflects its value. Inflating this price is not in our best interest. This larger price would communicate to those fitting the bill that there are more features, larger resources dedicated to customer service and bloated expansion towards bells and whistles. This is not our perspective on Unify. Unify is a simple tool, like a hammer; it does not bludgeon better with a different name on the side.

Also, there is an idea that comes up intermittently in our white-label discussions: that our “real” customers [designer/developers] want to be able to put their name on our product to make them look good. They are willing to pay five times the price – or more – so that they can tell their client that Unify is a custom-built CMS tailored to their needs. This, of course, is lying and is the worst possible justification for white labeling.

Truth be told, we want to look good, too. Not the “we” of Unit Interactive, but the “we” that makes Unify. We take pride in our product, and again, we want to build a brand behind that product that adds value and trust. We are not in the business of artificially inflating other people’s prowess. We only want Unify to be the best product for the people who have to use it every day.

High Anxiety: “My client will not understand why I charge my fee for a CMS when they can find that your product costs under $25.”

How a professional justifies their rates is not our business, but there is an easy answer to this: Time. Unify takes time to plan, install and to test (not much, though). One’s time is still worth money, so charge accordingly. If a person cannot rectify their rate with our price and their time, that person needs to sincerely reevaluate their pricing.

A Contrast in Black & White

“…black labeling is the practice of offering a ghosted service; where authorship, responsibility, or accomplishment (or all 3) are misrepresented in order to hide the truth of one’s inadequate skill, responsibility, or accomplishment. In plain English, by word this is known as lying; by deed this is known as deliberate deception.”

Here, Andy has drawn a decisive line between the honest uses of white labeling, and what he calls black labeling. By his definition only commodities can be appropriately white labeled. By our definition of what our actual product is – consistency of innovation, customer support, and a determination to keep things simple – Unify is a service. The code changes, but our commitment to serving to our customers stays the same.

Any attempt to white label Unify would really be black labeling, and would destroy Unify. This is not merely my opinion: it is the result of much internal debate and input from users – mostly to the contrary – that has led me to firmly stand against the ability to re-brand Unify. In most implementations, black labeling destroys brands and experiences. Where some argue that it adds consistency, it instead severely muddies the water for the people who are our main concern: the user. White labeling should be relegated to the few opportunities where it makes sense, and it is disheartening to see that it has become so ubiquitous in the life of a web designer.

Working with Multiple Agencies

Wednesday, August 11th, 2010

Unit’s approach to working with other agencies to successfully bring a client’s project to fruition is simple, straight-forward, and has had a genuinely positive impact on the quality of our work. It allows us to maintain professional relationships. It ensures the client receives our best effort. It enables close collaboration with the other contractors which provides the best possible results in the final product.

Despite these obviously desirable outcomes, our approach seems to be the exception rather than the rule in the web design and development industry. What follows is an explanation of the way in which we prefer to work and why it is the best-case scenario for our clients.

The Allegory of the Stool

To understand the client/agency relationships we encourage as well as why we believe they are effective, it is useful to consider a stool. Building a simple stool is not a particularly daunting task, but doing so successfully does require attention to a few critical details. The stool is the configuration of pieces (people) chosen to bring a project off.

The first critical element of a stool is the seat. The seat is the reason for having a stool in the first place and without a seat one can never have a stool. The seat is the project.

Next, one must add some legs to the stool in order to elevate the seat. After all, a seat on the ground does not a stool make. But how many legs to add? Can we get away with just one?

The One-Legged Stool

As it turns out, yes! A stool with only a single leg can be made to balance if it is carefully constructed and never disturbed. Yet, it is far from an ideal construction. It can tip in any direction and will do so when presented with the slightest turbulence. A person may sit on this stool, but not without constantly working to stay upright. Successfully using a one-legged stool is a precarious balancing act.

One-Legged Stool

A project set up as a one-legged stool provides many points of failure and inherent instability.

In the design world, one-legged stools come about because of the all-too-common practice of subcontracting. More explicitly, they occur when Agency One are hired to deliver all aspects of a project and then Agency One, in turn, hire Agency Two (or more) to handle aspects of the project Agency One aren’t equipped to handle on their own.

There are myriad issues with subcontracting and in his article Lies, Deception, and Subcontracting, Andy has written about them at length, but the short version is that at some level the agency is dealing dishonestly with its client.

At worst, the agency is deceiving the client into believing that the agency is capable of work it cannot do and must hire others to accomplish. In this situation the client is kept in the dark about who is actually doing the work and a facade of responsibility is maintained by the agency. Participating in such a scheme is not only bad news for the project, it is also patently unethical.

Not all subcontracting is based on deception however. An agency could be perfectly forthright with its client about what its true capabilities are and who will be doing which parts of the project. Unfortunately, even a transparent subcontracting situation is a dishonest one. The agency is still assuming responsibility for work it isn’t doing and people it doesn’t manage. They are still building a one-legged stool.

Project collaborations set up this way are so unstable because a failure at any point can topple the whole process:

  1. If the subcontractor fails, the agency can’t pick up the slack for work it couldn’t do in the first place.
  2. If the agency fails (or bails), the client loses all of its hired talent.
  3. If the client pulls out, the agency is left holding the bill for its subcontractors.
  4. Depending on the situation, any of the preceding can result in litigation.

At Unit, we flat refuse to be part of the house of cards that is a one-legged stool project. Most of us have had the experience at some point in our careers and were left understanding just how demeaning and unprofessional subcontracting really is.

The Two-Legged Stool

Two heads are better than one and so is a stool with two legs better than the contraption with just one. While inherently unstable, a two-legged stool is easier to balance on because it can only tip over in two directions. Its instabilities can be predicted and planned for by an alert sitter. Still, the stool is not constructed for success and sitter is solely responsible for keeping the seat upright.

Two-Legged Stool

Two-legged stools are usable but take a lot of work to keep upright.

Clients, especially those that are unpracticed at managing such projects, have a tendency to segment the workflow. Perhaps they prefer to first produce all of the design comps and then later worry about building the site out. Or maybe they desire a working product before considering the design. If the project is not segmented chronologically it may still be segmented by function with the client providing all of the communication between different agencies.

In whatever arrangements the pieces end up, a two-legged stool is created when the client works directly with the involved agencies (good) but the agencies work independently of each other (not as good). Everyone is in an honest business relationship and there are fewer points of failure, but the project is susceptible to two major flaws.

Chronological Segmentation: Every project has tweaks. Adjustments must be made as the various pieces are integrated. If the project is set up so that one agency must fully complete its work before the other begins, then these adjustments become a major hassle instead of a natural part of the project end game. The worst outcome of this is the loss of trust from the client’s perception of a job imperfectly done.

Function Segmentation: It is proper that different people should handle the aspects of a project that fit with their expertise. But if a client keeps these people ignorant of each other it is setting itself up to be the communications hub for people who need to speak a completely different language.

Clients are experts in their business (or should be if you are going to work with them). They are not experts in your field and trying to communicate with other experts through your client is an exercise in futility. Not only will the messages not be conveyed clearly, but since neither agency has a commitment to work with the other, both will be mainly concerned with protecting their reputation (and work) from the influence of the “other guys”. This is far from ideal and puts the quality of the finished product in jeopardy.

Two-legged stool projects are not the end of the world and they can produce great results, but they do so in spite of their flaws. We see our fair share of these projects at Unit but it certainly isn’t our preferred way to work nor is it what we suggest to our clients.

The Three-Legged Stool

A stool with three legs is fully stable. It stands on its own. It supports a weight without the active involvement of the sitter. It requires a strong jolt to upset the balance of a stool standing on three legs.

Three-Legged Stool

Three-legged stools are the most stable and best set up for success.

When the client is working directly with all agencies involved in a project, and those agencies are collaborating with each other, a three-legged stool has been achieved.

It is the best-case scenario for all involved parties. The agencies are only contracted to do the work they are best suited for. They all have a direct line to the client and each other so no intermediary translation is needed. They can collaborate to integrate and adjust the project without affecting project quality or disturbing the client’s trust. The ramifications of any one party’s failure is mitigated as much as possible. Best of all the work, and not the politics, is in the best position to receive everyone’s focus.

This is how Unit loves to work. Three-legged stool projects have demonstrated superior results time after time and so we recommend it to all clients seeking our services.

User-Centric Pricing

Thursday, August 5th, 2010

An article I wrote on pricing for applications is up on Smashing Magazine today. The article is written mostly from our experiences with Unify, with a little help from other fine web entrepreneurs like David Greiner of Campaign Monitor and Ryan Carson of Think Vitamin and Carsonified. This is an expansion of the thinking behind a post I wrote here not too long ago touting the benefits of proper pricing (and model) for the desired function of an app.

Price influences behavior, so it follows that user experience begins at the price point. When creating an app, think of the pricing model as early as possible, and keep adapting it to your user’s needs as well as your own through the life of the product.

Check out the article when you can. Your thoughts are definitely appreciated.

Your Clients Are Not Stupid

Thursday, June 24th, 2010

Designer smart – Client stupid. It’s a fairly common complaint in our industry. Granted, I hear it far less now that I work at a place that focuses on professionalism, but nonetheless the sentiment still finds a way to creep in around the edges. It’s easy to fall in to: “I worked REAL hard. They obviously don’t get it.” The problem is, the client paid for “it”, so you are kinda obligated to help them understand what “it” is and how “it” meets the agreed upon goals of the project, right?

Yes, a client can fail you. They may not be forthcoming with the right information, or they could throw it at you at the wrong time. I have found in my experience that this is not a matter of insufficient brain-stuffs. Clients don’t come with built in knowledge of how the creative process works, and this is an opportunity for you – the designer – to flex your expertise and bring your client up to speed. Advise, educate, and be unapologetic about getting the information you need to make the project a success.

My approach – well before writing off clients as imbeciles – is to evaluate if I have failed. Design chops aside, a healthy portion of this business is communication. If there is a breakdown in understanding during discovery, I may wind up on the wrong track and choose the wrong strategy. If everything runs smoothly, but the client repeatedly makes bad choices, then I am failing to adequately communicate the reason why those choices are wrong. Basically, if I find myself frustrated by my client’s position, I am probably neglecting some aspect of the conversation.

No matter how hard we work to understand our client’s business and motivations, we cannot be them. We will never understand their intent fully, so we do our best and every now and then, the client disagrees. It is how we handle this disagreement that makes us both better designers and true professionals. Take a breather and realize we all worked hard to get where we are. Business can’t suffer fools for long. Yes, a client may not be familiar with the nuance of typography or social media, etc., but that lack of experience is why they hired you. A client needs to focus on the myriad aspects of their business; you need to be the design expert and in most cases, a bit of an educator as well.

To even suggest that a client’s intellect is inferior because they disagree is just plain childish. Suck up your creative angst and try to see where they are coming from. Understand their motivations, or risk looking stupid yourself.

Recommended
Most Popular
Underappreciated