BlogmyQuery – BMQ

We recently did a post on how to tell your clients “No” which broke down the multiple considerations that need to be weighed when you are approaching this ground under these varied circumstances. Along with this handy online flowchart, Should I Work For Free? has you pretty well covered on that end. Now we bring you the other side of that coin: how to say “No” to other designers and developers that you might be working along side in any given project.

Let’s face it, we all know that there is a right way and a wrong way to handle these occurrences, however, when we find ourselves facing such a situation, we tend to just charge forward without any considerations being made whatsoever. This can lead to a number of issues arising out of this working environment unnecessarily, especially since with just a little more thought and effort on our parts, these potentially volatile situations can be diffused properly.

Just like we did in the last installment, we are going to start off by examining the various project points that we need to take under consideration before we boldly step forward and start throwing wrenches into the proverbial works. Once we have covered those things that we should always keep in mind, then we will look at the delivery itself for some final tips on moving out of the “Yes” person.

Is This a Personal Project?

First off, when you are working with another designer or developer and you come to a point where you have to tell them “No”, there are considerations that should be weighed that all fall in your path if the project you are working on is a personal one. This will determine the best way to handle the situation and proceed toward the project endgame.

Whose Idea Was It Anyway?

If you are working on a personal project then the first thing to consider when you are telling your teammates “No”, is exactly whose idea is this project that you are tackling? This helps to make your course of action a little bit clearer. Or rather, it should. After all, if the idea that gave rise to this whole project is yours, then telling the others “No” on suggested solutions or approaches is not like you are challenging them, it is simply like you are holding to your original vision. It is your project and you have a solid idea of how you want to achieve it. So telling the others “No” is a bit easier.

However, on the reverse side of that, if the idea for the project was not yours, then telling the others “No” can seem more like you are challenging their ideas and implicating that you know what is better for their project than they do. So you have to naturally handle those instances with a gentler approach. Not only that, but if the project was initiated by someone else, then you have to understand that your objections may not stand, and the others might proceed in spite of them. That is something else that you have to be prepared for. Also, in these cases, remaining insistent and clinging to your objections will only tend to complicate the working environment and relationships, so be prepared in team situations and to accept compromises.

Be very careful when saying “No”! Image Credit

Even if you are a key player in making this project see the light of day, if the idea for the project belongs to someone else, then they tend to be the understood head of the hierarchal structure and therefore, all final decisions should be left up to them. After all, it is their vision — we have merely agreed to help them see it through.

In Short:

• If the idea for the project is yours, then saying “No” is easier as it is expected to be your responsibility.
• If the project belongs to another, then saying “No” is more like challenging their vision.
• If the idea is not yours, then expect for your objections to be overruled and your cooperation to be expected to continue.
• Whoever’s vision brought the project into play, tends to be the final shotcaller.

What Part Were You Brought in to Play?

Another consideration that we need to weigh when we are thinking of telling other designers or developers on our team “No”, is the part that we were brought in to play on this project. Our expertise is usually what gets us into this position and it is this expertise that we are expected to bring to the table. So when we find ourselves on the verge of saying “No”, we have to consider if the impacts of this objection fall strictly under the umbrella of our expertise or not. Is this simply a personal objection that we have, or is it our skills telling us that this is not the way to go forward. If it is our expertise that is warning us about this way forward, then we should always speak up. After all, that is what we were brought in for.

If it is a personal reason that we have, then we may not feel as obligated to mention it or voice our objection, which might be the right way to proceed. If we have a personal disliking of the color orange, but for the project it communicates well with the message, then yes we should more than likely let it go. However, if it is a choice being made which takes the project places we do not feel comfortable with, and which we believe can hurt the integrity of the project then our personal objections need to be heard. For the comfort of our working environment and for the project itself. Chances are, we are not the only ones who will have this reaction. These reactions are another perk of having your perspective on the team.

When we are working as part of a team, it is easier for us to be able to step outside our role as collaborator in areas that are not strictly under our expertise, and into the role of user. Many valuable insights can be gained in juggled perpsective, and often times we are brought into a project so that we can provide both personal and professional project assessments.

In Short:

• Both our expertise and our personal reactions can favorably impact the project when we constructively voice them.
• Anytime our expertise urges us to object, then we have an obligation to tell our teammates our concerns.
• Our personal objections that do not fall under the umbrella of our expertise can provide valuable insights to the project from a user’s perspective.
• Not all of our personal objections are necessarily vital to the project’s course of action.
• If a projected course makes us uncomfortable in any way, we also have an obligation to tell our teammates about our objections.

Is There Room to Compromise?

Whenever we are working with others and we come up against a barrier which makes us inclined to tell our teammates “No”, we have to consider this before we act: can we find a way to make this work without compromising our reputation or personal code? If the answer is yes, then perhaps we should accept this compromise and move on with the project. After all, whenever we tend to be attached to a personal project, we tend to be doing so for the fun of it all. So if we do not have to make things unnecessarily complicated, then why not keep with the spirit in which we signed on to the project in the first place and just roll with it?

Even if the project is one that we initiated, there are times, when we may find that yielding to the expertise of those we are working alongside is the best possible course of action for the project. So if we can find the room to compromise and still reach our desired outcome, then what is the harm in being flexible from time to time. In fact, these kinds of compromises can serve to keep the entire team morale up, and that is always good for the working environment of the project. If the others always feel as if their ideas are being shot down, then their level of interest and passion for the project may start to decline.

In some cases, compromise might not just be the best way forward, in order to get your project to see the light of day, it might be the only way forward. Sometimes our lack of expertise in areas of the project could be a hindrance if we do not leave ourselves a little bit of room to compromise.

In Short:

• If we can reach a compromise without compromising ourselves or the project outcome, then it may be the best way forward.
• Most personal projects are began out of fun, compromising could help maintain that spirit and tone for the project.
• Compromising with your teammates can help to keep up morale during the course of the project.

Where Do You Go From Here?

Whenever you feel that you must tell the other designers and developers with whom you are working with on a personal project “No”, another fact to consider would be the future. Not only the projects, but yours as well. Does this mean the end of your inclusion in the project? And if it does, do you wish to work with these people again in the future? If it is your project and you are telling them “No”, does this mean the end of their parts in the project? Which in turn, could mean the proverbial back burner for the project until you can replace them. Or worse, it could spell the end of the entire project altogether if they cannot be replaced.

So where things do go from here, plays a big part in how we handle this situation for sure. If we wish for the project or the working relationships to continue, then we need to handle the “No” with kid gloves and find ways to soften the blow that this kind of rejection can inevitably be packaged with. Explain the reasons why we strongly feel that this is not the right course of action. Try to control any negative wake left behind us. Whereas, if we feel that our involvement in both the project and working relationship has run its full course, then we do not have to dress up our objections — we can simply let them be voiced and let their impacts have whatever wake they might.

This is not to say that we should ever set out to burn any bridges in the design or development communities, no. But more saying that there are instances where we will inevitably care less if our telling others “No” has lasting effects upon certain projects or groups. Then there are going to be others where we are careful to ensure that we leave things in a more positive way.

In Short:

• In personal projects, where our “No” leaves things overall, should still be a concern for us.
• If this means the end of our involvement with the project or the other designers and developers, and we wish to work with them again, then we should handle this with tact and care.
• If this means the end of our involvement with the project of the other designers and developers, and we do not care to work with them again, then we tend to handle it more bluntly.

Is This a Professional Project?

Now we come to the considerations that you need to weigh when you are working with other designers and developers on a professional project and you have to reject an idea of theirs for one reason or another. Given that on professional projects there tends to be money and contracts involved, you saying “No” can have much heavier repercussions, and therefore deserve even further considerations than have already been discussed.

Who Brought Who On Board?

Just like who the idea belongs to on a personal project can establish a sort of hierarchical structure to the working order, on professional projects, who brought who on board the project can also attach the same structure to it. Now, naturally the client gets to set the pecking order however they see fit, though as a matter of professional courtesy, if you have been brought aboard the project by another, then you might want to first voice any objections you have to them. After all, it could end up reflecting upon them anyway, given that they are the reason you are working on the project. So why not give them a heads up?

Now if we decide that we must tell the others that we are working with that we are not going to comply on something, and we first go to the person who brought us on board, we have to understand that we effectively put our way forward in their hands. If they listen to our concerns and decide that we should not press this issue, but instead compromise, then we might just have to accept that and move on — one way or another. Either by accepting their decision or leaving the project if we feel we must. Or if they decide to push the issue with us, then we at least have an ally as go forward with our concerns. But either way, if we take it to them first, then we are not only acknowledging this hierarchy, we are somewhat agreeing to follow it.

This is not to say we cannot challenge their decision by further voicing our concerns, it just says that once we have acknowledged their position in the structure, going around it tends to come with heavy consequences. This should be known before we proceed.

In Short:

• If we are brought into the project by someone else, then it can reflect on them when we say “No” to the others on the team or refuse to comply.
• It might be considerate to first voice our concerns with the one who brought us on board out of professional courtesy.
• The one who brought us on board can effectively be installed as the one who decides our course forward.

Should This Go Over Any Heads?

Another consideration that we have to make when we are telling the other designers or developers that we are teamed with a “No”, is how far up the proverbial chain should you go? Is there any reason for our concerns or objections to be taken beyond just the other members of our team? Given all that it is involved once again in a professional project, with regards to revenue and contracts, we have to decide if what we find ourselves coming up against warrants full disclosure to the higher ups, or if in fact, this is a concern that could be worked out amongst the team ourselves. Here we tend to let the situations guide and gauge our responses.

For instance, if we are working in a team and another asks us to help cover them by picking up some of their slack, we might be able to decline without it being a big deal. However, if we find that this same person is always asking for our help to pick up their slack, thus effectively dragging the project down with them, then we might have to take our objections a little further and let someone else above us know exactly what is going on. This way they can take the necessary actions to improve on this aspect of the team or project environment. After all, there are bottom lines to be considered.

So there are times when we find that it is simply not enough to tell another member of the team “No”, but that we have to take these objections to others in order for them to have any true impact on the project at hand. This is not always an easy or popular route to take, but it tends to always be the route that best serves the project in the end.

In Short:

• There are times when it is not only appropriate, but it is necessary, to take our objections further than to just a single member of the team, or to just the team itself.
• Given the weight attached to professional projects, sometimes saying “No” to another teammates may not be enough.
• Situational indicators can often determine how high up the chain of command to go with our objections or concerns.

Where are the Deadlines and Relationships?

Another consideration that has to be made when you are telling other designers and developers “No”, especially with a professional, paid project, is the impact your objection will have on the overall project deadline. Now this is not to suggest that you should bite your tongue just to meet the looming project end date, only to say that you should keep this in mind when you handle how to approach this “No”. Your approach is further determined by the status of your working relationship with the others within the team. The stage that you are at and the distance you have between you and deadline can determine how you tackle any project refusals.

If things are just getting started, then the rejection of ideas is natural in what tends to be the brainstorming stages. If you are new to working together, and just getting started there, then again it is natural to reject each others ideas as you feel each other out, even though you may feel reserved and a bit guarded. During the middle of a project or pairing, as things are more entrenched and people are more invested, then telling someone “No” can be trickier. More tact tends to be required and you have to be more willing to propose alternatives not to just reject out of hand. In the latter stages of a project more tends to be required than just a rejection, we have to be willing to explain ourselves. Though in the latter stages of a working relationship, this rejecting of ideas gets easier once again, and less complicated with ego and pride even with a deadline looming.

So where you are at in the project and in the partnership with the other designers and developers can also effect the way your rejection is taken by the other members of your team. And they should also be given their full weight and consideration as you prepare to tell them “No”.

In Short:

• The stage you are at both in the project and the working relationship can effect not only how you approach telling the others “No”, but also how they take it.
• The project deadline should never be out of focus as you discuss your objections, in fact it should define your approach.
• The closer the deadline, the more comprehensive as well as helpful your rejections should be.
• The more developed the working relationship, the easier telling your team members “No” will be.

Where Do You Go From Here?

Just like with the personal projects, in professional ones, you should consider where exactly this saying “No” leaves you. Always ask yourself how this will impact the future. Is this going to have an impact on the rest of your time with this company? Are you going to have to work with these other designers or developers again on future projects? And of course, you always have to ask yourself, do you care if these areas are effected by your decision to decline an idea or say “No” to a project? Though admittedly, the answers to those questions rely heavily on just what it is you are being asked to do that you are turning down.

For instance, if you notice that your company is trending towards taking on clients that you find more and more objectionable (for whatever reason) then you might be fine with letting some bridges burn as you refuse to comply. Even if you know it could mean the end of your time with the company. In which case, be as open and honest as to why you object to the work and be sure that it is gotten on record. However, if you find that it is only one particular project that you find yourself on where you feel you must say “No”, and you do not want it to negatively impact your stay and status with the company and the others you work with, then you might want to find more even-keeled approaches to these refussals.

When it is all said and done, we may not have a choice as to who we are going to be partnered up with from project to project, but as long as we know where we are hoping to end up in the end, then the way forward tends to become clear. Not only that, but the way to handle saying “No” also gets a little easier to see.

In Short:

• Always keep where you want to go from here in mind when you are saying “No” in professional projects, just like in personal ones.
• If you feel like the company you work for is beginning to take on more clients that you object to, and you do not care to remain with the company, be open and honest.
• If you feel like this project that you object to is not the norm, and you wish to not have your refussals hurt your future with the company, be more tactful and less confrontational in your approach.

The Act Itself

Now that all of those other considerations have been made, there are some underlying rules to handling these kinds of refusals that you want to keep in mind. These do not vary much from the rules we talked about in the client post, however they apply here as well so we had to cover them too. The other designers and developers that you are working with, or that you could potentially be working with tend to appreciate when we adhere to these guidelines in our rejections.

The Golden Rule

First things first, whenever you are telling another designer or developer “No”, remember the golden rule: Do unto others as you would have them do unto you! It applies here as well. We have to remember that whenever we tell someone “No”, there is a chance that they might not take it well. So we need to put ourselves in their places. If you were in their shoes, how would you want this to be done? This should at least ensure that, above all else, we handle these situations with some modicum of respect.

Even if you know that bridges may get burned in the process, as long as we take their feelings into consideration, we will come out of the situation having walked the higher, more respectable road. As we have said before, not many people respond favorably to being told “No” about anything, but if we always come from a place of respect and understanding, no matter what we are met with in return, then we have done all that we can to ease this possible blow. It may not be the easiest approach to take, but it tends to produce some of the best results.

In Short:

• Put yourself in their shoes, and ask how you would like to be treated in their situation.
• Always be respectful when you are telling others “No” — it tends to make the situations less volatile.

The Courtesy Call

Speaking of respect, the next rule of handling these situations tends to come from this same arena, and that is the rule of the courtesy call. This is not always a literal call, as much as it is a virtual heads up, so to speak. You never want to just leave the requests that you have received from other designers and developers unanswered and unaddressed. You should always take a moment and do them the courtesy of getting back to them on whatever issue they have sent you to tackle or provide your take on. But unfortunately, in this fast-paced business environment, timely returns on their requests are not always possible. Couple with that, that usually we are not in any big hurry to forward our rejection so we tend to backburner our ‘No’s rather than send them along in a timely manner.

However, none of this means that we should just give up on getting back to them altogether and just continue to work the project without communicating with the others you are teamed up with that you will not or cannot comply with their request. Often times, when someone from the team reaches out to another member of the team, for most any reason, they will put themselves in somewhat of a holding pattern until they hear back. Causing the project progress to potentially grind to a halt while we ignore the issues or queries sent to us via the team. So we should always take a few moments each day and reply back to any project inquiries or change requests that we have gotten that day, whether we feel like addressing them or not.

In Short:

• Be courteous enough to reply with your declines in a timely manner.
• Do not leave others hanging in a holding pattern because you do not want to tell them “No”.
• Take a few moments out of each day to specifically address any other team member concerns you have been sent.

Never Be Vague

Another rule that makes a huge difference in the refssal arena, is one that we covered in the previous post, but whose relevance remains intact in this case, and that is not beat around the bush with your declines. Often times in order to ease the blow of our disagreement or objection to something in the project, we tend to not be as direct about the whole thing as we should. But you want to be sure that everyone understands that you are giving a definitive “No”, and to do that, we have to make sure that we are not being vague at all, but instead are giving a clear signal that is not going to confuse the issue.

In Short:

• Always be as clear as you can when saying “No” and use concise language to not confuse the issue.
• Do not let your discomfort with deciding to decline allow you to be vague and dance around the issue.
• Everyone always needs to be on the same page, and your decline is no different.

Be Forthcoming When Appropriate

When you are dealing with other designers and developers that you are working with on a project and you feel like you must say “No”, then you want to be as forthcoming with the details as you can appropriately be. If you can, provide them with more than just a “No”, give them a glance at your reasoning. If there is a particularly bothersome element of the project that makes you uncomfortable, they might eliminate this troubling element in favor of bringing you on board or keeping you on board. Naturally, there might be some of the reasons that you wish to keep to yourself, and that is completely acceptable. But when and if you can, provide them with some insight behind your decline.

In Short:

• Try not to just tell them “No”, but to give them a peek at your reasons when appropriate.
• This is not arguing for full disclosure across the board, but some idea as to why you are declining is respectful and appreciated.

The Tone Tells It Like It Is!

Just like we discussed in the last post, any time we are communicating with others, we have to be aware of our tone at all times. This is one of those understood communicative rules, but one that we still tend to forget in this digital age where many of our communications take place in the virtual realm where our tone of voice does not accompany our words, and nearly any tone can be applied over the top of them. This is not always within our control, but it does allow us to remain alert and watch out for our tone to say more than we intend it to. Going over our thoughts or messages before we share them is key for helping to safeguard against this unintended tone attachment.

In Short:

• In communication, especially in today’s digital world, it is quite easy for the tone of our words to be misinterpreted.
• Vet your thoughts and messages for instances where unintended tones can be applied.

That’s That!

That wraps up this side of the discussion, but once again, we turn the topic and the dialog over to you. Feel free to keep dissecting this discussion in the comment section below, or raise any points that you disagree with, not to mention those you feel were not covered enough (if at all). So take the reigns and keep the topic growing below.

Consider Some of our Previous Posts:

• When Designers and Developers Work Together is a post to check out for more on how designers and developers can work alongside one another.
• Improving Client Relations and Enhancing the Work Process: for all of you out there who are having difficulties with clients.
• Breaking Down the Design Process: knowing when the price is right!

(ik)

Everybody (well, everybody who designs or builds websites for a living) wants people to stop using Internet Explorer 6. Even Microsoft does, so much that they recently launched The Internet Explorer 6 Countdown.

On the site, developers and website owners are encouraged to tell their IE6 visitors to upgrade. The site also shows current browser statistics per country so we can keep track of how IE6’s market share is shrinking.

This is a good initiative, but there is room for improvement.

Read full post

Posted in Browsers.

User experience design for the Web (and its siblings, interaction design, UI design, et al) has traditionally been a deliverables-based practice. Wireframes, site maps, flow diagrams, content inventories, taxonomies, mockups and the ever-sacred specifications document (aka “The Spec�) helped define the practice in its infancy. These deliverables crystallized the value that the UX discipline brought to an organization.

Over time, though, this deliverables-heavy process has put UX designers in the deliverables business — measured and compensated for the depth and breadth of their deliverables instead of the quality and success of the experiences they design. Designers have become documentation subject matter experts, known for the quality of the documents they create instead of the end-state experiences being designed and developed.

When combined with serial waterfall development methodologies, these design deliverables end up consuming an enormous amount of time and creating a tremendous amount of waste. Waste is defined as anything that is ultimately not used in the development of the working product.

Engaging in long drawn-out design cycles risks paralysis by internal indecision as well as missed windows of market opportunity. Image by opensourceway.

As organizations struggle to stay nimble in the face of an ever-changing marketplace that is disrupted constantly by incumbents as well as start-ups, getting to market fast becomes top priority. Engaging in long drawn-out design cycles risks paralysis by internal indecision as well as missed windows of market opportunity. In other words, by the time the company decides internally how the product should be designed, the needs of the marketplace have changed.

Waterfall software development looks something like this:

Define → Design → Develop → Test → Deploy

The design phase typically breaks down like this:

Wait for requirements definition to take place and get approved →
Consume requirements documents →
Develop high-level site maps and workflows →
Gain consensus and approval →
Develop screen-level wireframes for each section of the experience →
Present to stakeholders and gain consensus and approval →
Create visual designs for each wireframe →
Present to stakeholders and gain approval (after repeated cycles of review) →
Write The Spec, detailing every pixel and interaction →
Usability test for future improvements →
Hand off to development for review, approval and start of implementation

This phase can take anywhere from one to six months depending on the scope of the project, leaving many wasted hours and much designer frustration in its wake.

Enter Lean UX.

Lean UX

Inspired by Lean and Agile development theories, Lean UX is the practice of bringing the true nature of our work to light faster, with less emphasis on deliverables and greater focus on the actual experience being designed.

Traditional documents are discarded or, at the very least, stripped down to their bare components, providing the minimum amount of information necessary to get started on implementation. Long detailed design cycles are eschewed in favor of very short, iterative, low-fidelity cycles, with feedback coming from all members of the implementation team early and often. Collaboration with the entire team becomes critical to the success of the product.

Interestingly and not surprisingly, one of the immediate casualties of Lean UX is the stereotypical solitary designer, working silently in a corner for a period of time, inviting only occasional peeks at their work before it’s “done.� This mindset is also the biggest obstacle to wider adoption of this practice.

Let’s take a look at the Lean UX process:

Stay lean and focus on the experience, not the paperwork.

Looks familiar? It should if you’re familiar with Agile or its derivatives. Lightweight concepting kicks off the process. This can be done on a whiteboard, a napkin or a quick wireframe. The goal is to get the core components of the idea or workflow visualized quickly and in front of your team.

The team begins to provide their insights on the direction of the design as well as its feasibility. Changes are then made to the original idea, or perhaps it’s scrapped entirely and a new idea proposed. The initial investment in sketching is so minimal that there is no significant cost to completely rethinking the direction. Once a direction is agreed upon internally, a rough prototype helps to validate the idea with customers. That learning helps to refine the idea, and the cycle repeats.

What’s most important to recognize here is that Lean UX is focused strictly on the design phase of the software development process. Whatever your organization’s chosen methodology (waterfall, Agile, etc.), these concepts can be applied to your design tasks.

Isn’t This Just Design-By-Committee?

Lean UX encourages you, the designer, to show your work early and often to the team, collect their insights and build that into the next iteration of the design. To many folks, this sounds like the dreaded “design by committee� approach, which has killed many designs in years past.

In fact, the designer is still driving the design by aggregating all of that feedback, assessing what works best for the business and the user, and iterating the design forward. By providing insight into the design work to your teammates sooner rather than further down the design road, you accomplish the following:

1. Ensure that you’re aligned with the broader team and the business vision;
2. Give developers a sneak peek at the direction of the application (speeding up development and surfacing challenges earlier);
3. Further flesh out your thinking, since verbalizing your concepts to others forces you to focus on areas that you didn’t think of when you were pushing the pixels.

The trick is to stay lean: keep the deliverables light and editable. Eliminate waste by not spending hours getting the pixels exactly right and the annotations perfect. Got an idea for a flow? Throw it up on the whiteboard, and grab the product owner or project leader to tell them about it. Ready to design? Rough out the first page of the flow in your sketchpad. How does it feel? Is the flow already evident? Post it in a visible place at the office and invite passers-by to comment on it.

In the Lean UX methodology spending time on realistic goals and informed design decisions is crucial. It helps to effectively match expectations and reality for your clients. Image by Kristian Bjørnard

As you iterate, suggestions and feedback from various team members will inevitably start to manifest themselves in the experience. The team members who suggested these ideas will begin to feel a sense of ownership in the design and notice it in others. It has now become something they had a hand in creating. This sense of ownership will equip the designer with new allies to defend the work when it comes under criticism from external forces. The team ultimately becomes more invested in the success of the experience.

Lean UX Is Not Lazy UX

It may seem at first that this is a lazy approach to UX, that the goal is simply to do less work. On the contrary, you’re actually using all of the tools in your UX toolkit. Sketching, presenting, critiquing, researching, testing, prototyping, even wireframing — these all get a solid workout in each cycle of the process. The trick is to use these tools when appropriate and, more importantly, to use them at the depth appropriate for the immediate problem you’re trying to solve for the business.

Designers Need to Feel in Control of Their Work

“But I’m giving up control of my design!� is one of the most often-heard complaints from designers who try out Lean UX. Their concern is that by collecting feedback from non-designers, they will be less valuable to the team and be relegated to the role of menial pixel-pusher.

Holding on to the concept and avoiding the unnecessary is vital in Lean UX. Image by Kristian Bjørnard

By staying lean, however, the frequent collection of team-wide feedback actually minimizes the time spent heading down the wrong path. The designer continues to drive the design, but the guardrails (i.e. constraints) become more visible with each iteration and review. Basically, if you spend three months perfecting a design only to find out after launch that it fails to meet customers’ needs, then you’ve just wasted three months of your life, not to mention your team’s.

Lean UX also speeds up development time. By giving the team early insight into the design’s direction, it can begin to lay the groundwork for that experience. This foundational coding phase helps to expose feasibility challenges in the proposed solution. The time, material and resources available then help to prioritize the product’s elements, separating the parts that get built from those that get pushed out or reduced in scope. All of this affects where the designer focuses their energy, thus minimizing waste.

Prototyping: The Fastest Way Between You and Your Customers

Lean UX is where prototyping shines. As with the initial sketches, focusing the prototype on critical components of the experience is essential. Pick the core user flow (or two), and prototype only those screens. The fidelity of the prototype ultimately doesn’t matter, so create it the way you know best. Once created, it will be immediately testable by any and all users.

Successful lean prototypes have been created with code, with design software such as Adobe Fireworks and even with PowerPoint. At times, your client (internal or external) will demand a level of fidelity that helps them better visualize the experience. Work with the tool that is most comfortable and fastest for you and that delivers just enough fidelity for the client.

Next, get that prototype in front of everyone who matters internally, and validate whether you’re meeting the needs of the business.

Diagram of the iterative design and critique process. Warfel, Todd Zaki. 2009. Prototyping: A Practitioner’s Guide. New York: Rosenfeld Media.

Most importantly, get the prototype in front of customers. Bring them in regularly to test the workflows, ideally once a week. You don’t need to test with many customers. Jakob Nielsen found out that after five participants, the odds of finding new roadblocks in the experience were low. If you test regularly, you can cut the number of participants per week to three. This will also cut costs.

Collect feedback. Figure out what worked and what didn’t. Tweak the prototype. Hell, gut it if you have to: that’s the beauty of Lean UX. The investment you’ve put in at each phase is so minimal that rethinking, reconfiguring or redesigning isn’t crushing in workload or ego-bruising.

Once validated, demo your updated prototype to the team. Explain the flows, the user motivations and why you designed it the way you did. The prototype has now become your documentation. It is “The Spec.� Very little (if anything) more is needed. Regardless, you’re there to answer any questions that come up. The strength of Lean UX here is that, with the design validated, the designer is now freed to move on to the next core component of the experience, instead of spending six weeks creating a design-requirements document and pixel-perfect specs.

Prototyping puts the power of validating the design’s direction much more quickly in the hands of the ultimate decider: your customers. They are the ones with whom the design will speak for itself, and in the environment where it will ultimately have to succeed.

Maintaining a Holistic Vision

“But what about my vision? By chopping the design up and delivering it piecemeal to the team and, ultimately, customers, I’m compromising on my vision of the product and putting out a sub-standard experience!�

Lean and Agile Development are called for! Image by Kristian Bjørnard

UX designers have traditionally worn many hats. You now have another to add to the hall tree: keeper of the vision. In this new role, your responsibility is to keep an eye on the big picture. Lean UX forces you to think of the experience in prioritized chunks. Ultimately, those chunks all have to roll up into one cohesive product. That cohesive product is your vision. Even as the design shifts and morphs through iterations and customer feedback, you are always designing towards that greater goal. “Increasing time on site for returning customers� could be a vision. “Deliver content faster and in a more contextual manner� could be another. Regardless of how the design shifts, these goals drive your work.

It won’t be easy. In the past, those hard-won, comprehensive, approved deliverables authorized you to design in a specific direction. With Lean UX, the iterative cycle and the frequent varying opinions will inevitably create conflicts with your vision. This is where you push back. Use the stated vision to help sort out conflicting feedback and focus your efforts on the end goal.

Deliverables For Maintenance Don’t Make Sense Anymore

Documentation has long served as a way for organizations to maintain their software. It becomes a reference tool to understand the decisions of the past, which inform the decisions of the present. While this may make sense for complex business rules, it doesn’t make sense for design. The final product is the documentation. It is the experience. Thick deliverables created simply for future reference regarding the user experience become obsolete almost as soon as they are completed. When a question arises about how something should behave in the UX, going through that workflow in the product to see what happens is easy enough. The old kind of documentation is waste and draws effort away from solving current design problems.

How Does Content Strategy and Planning Fit In?

Websites and applications that are focused on heavy content delivery (as opposed to task- or function-based websites) will need some up-front planning and documentation. Getting right down to the level of the page and article may not be necessary, but getting enough of an idea of the type of content that will be delivered and a sense of its hierarchy is essential to getting to that first sketch and prototype. Once the team grasps the scope and type of content needed for the experience, work can begin as the experience is refined.

Can It Be Done At My Organization?

At the risk of oversimplifying, let’s look at two types of organizations: the internal software/design shop and the interactive agency.

For internal software/design organizations, the transition to Lean UX is well within reach. You are in the problem-solving business, and you don’t solve problems with design documentation. You solve them with elegant, efficient and sophisticated software. Working in these new attributes should ultimately be an easy sell internally because you are advocating for more collaboration, more conversation and earlier delivery to customers. Yes, the culture will have to shift — shipping what amounts to the minimum desirable product can be a tough pill to swallow for those used to big-bang releases. However, the ability to make quicker decisions along the way, informed by regular customer feedback, should ultimately trump these concerns.

Interactive agencies have it a bit tougher because they are in the deliverables business. They get paid for their documentation and spend a lot of time creating it. A specialist creates each document, and they charge for that time. Reducing those efforts means reducing revenue.

Lean UX proposes that the shortfall in up-front revenue generated by deliverables can easily be made up, and then some, by delivering higher-quality work, faster, to the client. The process has to be modified slightly, though:

Lean UX process for an interactive agency.

The core difference with the agency’s process is the regular and frequent involvement of the client. Set up twice- or thrice-weekly 30-minute reviews with them. Set the expectation that you’ll be showing rough, directional work and that you’ll want their feedback. Each time you review a directional sketch with your client, they’ll notice the evolution and progress. Their feedback will work its way in and, like an internal stakeholder, they’ll gain that sense of ownership.

By involving the client in the process, by iterating the design quickly and by testing the iterations with real customers, you will reach an optimal solution in less time than before.

In agency-land, less time typically means less revenue, which could potentially be the death knell for Lean UX. But while the output took less billable time to create, it will likely be more effective and will bring the customer back to your shop more frequently than in the past. In addition, you’ve made the client part of the process. This is empowering, and clients like that feeling.

This is not an easy change because agency culture has been the same for many decades. Only the boldest agencies will take this on. But those that do will find greater success from it and will quickly be imitated. These ideas are worth piloting on an internal project; perhaps the redesign of the agency’s website. Prove that they work, and then branch out to actual clients.

I’m a Consultant/Freelancer. Does This Make Sense for Me?

Consultants are, in essence, an agency of one. It stands to reason that the agency process could work in this situation as well. Constant feedback and iteration with the client will engender the same feelings of trust and co-ownership. The challenge for the consultant/freelancer is the amount of time they can dedicate to each client. Assuming they can handle multiple projects or clients simultaneously, providing the level of attention and communication necessary to maintain a true Lean UX process becomes difficult. In this case, falling back on a slightly deeper level of documentation makes sense to keep concurrent projects moving forward.

Optimize your workflow and win time. Image by Kristian Bjørnard

It’s worth mentioning that one big challenge for Lean UX to be successful in any of these settings is the use of offshore development vendors. One of the fundamental principles needed for Lean UX to succeed is collaboration — ideally in real time and place it can even work via Skype or other virtual meeting technology. When a vendor has minimal contact with your design group and requires a certain level of documentation in order to produce work, Lean UX may not work in its entirety.

Lean UX is being actively used by a growing number of organizations. The way TheLadders has implemented it in a recent effort is an example of keeping deliverables light, fostering greater collaboration and achieving goals successfully.

Conclusion

Lean UX is an evolution, not a revolution. UX designers need to evolve and stay relevant as the practice evolves. Lean UX gets designers out of the deliverables business and back into the experience design business. This is where we excel and do our best work. Let’s become experts at delivering great results through these experiences and forgo the hefty spec documents. It won’t be an easy road. Culture and tradition will push back, yet the ultimate return on this investment will be more rewarding work and more successful businesses.

(al) (vf) (sp)

© Jeff Gothelf for Smashing Magazine, 2011. | Permalink | Post a comment | Smashing Shop | Smashing Network | About Us
Post tags: usability, ux