Fake Affordances

Let’s talk today about Fake Affordances pattern described as:

Is there anything to be gained from making something look like it works one way, while actually doing something else (or nothing at all)?

Example:

Many elevator/lift ‘door close’ buttons are reputedly ‘placebo buttons’, giving an illusion of control but not speeding up the process.

This is the best ever defined management-under-stress technique. When the project has a high visibility, tough delivery schedule or high risks there is an extreme attention from stakeholders. Thus, you have to manage not only the internal delivery itself but external control over it. The same problem exists when delay or non-crucial fail happens. All stakeholders are trying say what to do and how to fix.

Frankly speaking, in most cases you know the reasons and actions required yourself. Each suggestion slows you down. Each external influence affects the team. Thus, feel free to accept any suggestions and promise corrective actions just to give feeling of control to your stakeholders. This will save you time and keep your team focused.

You can use it with boss of your boss as well. Sometimes it happens when a top manager is trying to micromanage. He might be wrong due to lack of information. However, due to his power you cannot say “No” or “Maybe”. He expects immediate action. Thus, give a fake promise if needed. He’ll get what he wants: a feeling of control. And you’ll avoid acting the wrong way. At least immediately.

Disclaimer: there are two issues with this pattern. First, you might me be wrong. Second, you might be considered as a liar. Both are disaster to you. Take care.

Inspired by: http://www.danlockton.com/dwi/Fake_affordances

Advertisements

Angles

The next pattern I’d like to talk about goes from Architectural Lens. It’s name Angles and described as:

Can you slant or angle things so some actions are easier than others?

Example:

Some cigarette bins are sold to authorities using the sloping top as a feature, discouraging people leaving litter on top.

This pattern has great use in management. Policies, roles, organizational chart, titles, departments and so on makes the corporate environment rectangular. Everything has a definition and purpose. Unfortunately, it decreases the flexibility.

There are cases when rules set in the rectangular world don’t let you to achieve your goal and do a specific action. Think about changing the angle. It might help.

Let me give an example. You have a new project. You clearly understand that you are the right person to start it. However, if you become a project manager during the kick off your chances to step back are low. Customer will not accept this move. You have a dilemma: whether to let the project start slowly without you, or you do fast kick off and have to take part in it for a long time due to rectangular rules.

The solution is to call yourself an engagement manager and do your job. Don’t care if this title doesn’t exist in your company.

It is nice practice to change your title, organization chart position, role in the project or department name to ‘hack’ the system. This is exactly changing the angle solution. You are forming the layout that makes some actions difficult to make. E.g. if renaming project manager to engagement manager you make it difficult for the customer to keep you on the project for a long time.

Every time you face obstacles due to rectangular policies, job definitions or reporting dependencies think about changing the angle that creates new surface and makes your life easier.

Disclaimer: you should know that most of the people don’t like non 90 degrees things 😉

Inspired by: http://www.danlockton.com/dwi/Angles

Hiding Things

The pattern for today is Hiding things. Original description says:

Can you hide functions or elements you’d prefer people didn’t use?

And example is:

These church hall heating controls have been hidden (leaving only the timer accessible) to reduce errors by users unfamiliar with them

In managerial world this pattern has two major applications. Positive and negative as you guess. Being the good guy by nature I’d like to start with the positive one.

Hiding things is the good approach for writing documents, policies and so on. 80% of long document is a kind of over-complication. The core message usually takes less than two or three paragraphs and is useful for the most readers. Ten more pages are about minor details and facts behind the proposal. Just split your writing into two parts. A short message to fulfill  the needs of most of your users and a number of pages to provide background and details for some of them. Save the time to your readers.

I’m always looking for the executive summary section. In most cases it works perfectly well. All other chapters can be just scanned that saves time.

Unfortunately, the most positive pattern that makes usability happen in the real world becomes the dirty trick in the communication. This pattern is the brilliant way to put something in writing that not welcomed by the recipient. Just let me show several examples.

The first one is about corporate policies. Have you ever read them? The bigger company is the more complicated they are. As the result it is perfect place to hide something. E.g. your company has a policy that allows ordering pizza or taxi on a specific occasion. However, to use them you should find the right regulatory document. Surprisingly, there is no pizza or taxi ordering policy. It is part of a 60-page-long office space regulatory policy. Those who are aware are using the service. Others are suffering from the pattern. Whether it was done on purpose or not is the question to you. Bad author does it accidentally. The good one does it on purpose!

Another usage of this pattern is emailing. There are cases when you need to put disclaimer, notification or fact into the message to cover your back. However, the counterpart wouldn’t ever confirm this information. So, it is your turn to do the dirty Hiding Things pattern. Write the long message with two or three messages in it. Put you tiny message (that is expected to be skipped by the reader) right after the tough and intriguing question near the end of the message and cross your fingers. In 50% cases if not used daily it works.

Disclaimer: whatever reason you have to hide something you should think from the reader’s perspective. The most awful thing is when writer of the document can’t understand the reader properly. Hiding Things is the most dangerous pattern in this case.

PS: If you don’t you like politics and avoid even thinking about dirty tricks you are not ready for anything more intriguing and interesting but a line management.

Inspired by: http://www.danlockton.com/dwi/Hiding_things

Simplicity

Today I’d like to talk on the architectural pattern Simplicity. Original description says:

How simply can you structure things, to make it easier for users to do what you’d like them to do?

And example says:

EcoButton allows a user to put a computer into a low-power state with just one press, making it much easier for users to save energy.

When I look at this pattern from managerial point of view I see that this is the way we should use modern methodologies. E.g. Agile, RUP, ITIL in IT world or Six Sigma or Balanced Scorecard in general management.

Usually, people see the problem and can identify the methodology that should fix it. However, than they fight for pure implementation of it according to the book.

That is the place where problem begins. Any methodology is always too general and universal for your exact case. You solve your problem but bring unnecessary complexity. You are starting to obey new rules that are artificial to your process.

And that is the place where this must use pattern comes. Just make the methodology implementation as simple as possible. Remove every single procedure, document or rule that is not relevant to your case. Try to identify exact subset of the methodology that fixes your problem and throw away the stuff that is not needed.

It is absolutely clear that this sweeping looks like bad methodology implementation. But why should you care? Just take care of the initial problem to be solved. And while removing unnecessary complexity think of the reasons it was introduced in the original concept. There might be something that you are not aware of yet.

PS: God bless people who care about making agile more simple rather than fighting for its purity.

Inspired by: http://www.danlockton.com/dwi/Simplicity

Nakedness

I’d like to start this post with my favorite saying:

A camel is a horse designed by committee.

There is a design-to-managerial pattern that might cause to the result from above. But only in case if applied incorrectly. In most cases it does work. It is described as:

Can you remove cues that people take for granted, to get them to think more about what they’re doing?

Example:

‘Naked roads’ with signage and markings removed can encourage pedestrians, cyclists and drivers to be more aware of each other’s presence.

That is a great pattern for management as well. If you want to find a cross-functional solution you should remove boundaries first. It does mean that if different levels of management and production people should find a solution together they should remove subordination rules.

E.g. if you want to find a cost saving opportunity and form a group of people from different departments with different titles to define the solution you should find the way to make them equal. Methods vary and can include rotation of moderator, adding a separate moderator who care of the result and ignore titles or defining the process when there is no way to use the power and so on.

This pattern is about making the structure flat when needed. It is tough step to do but worth it. The only and the very issue is to find the way not to build a camel when horse is needed. That’s it.

Inspired by: http://www.danlockton.com/dwi/Nakedness

Decoys

The next interesting pattern is Decoys. Originally it is described as:

Can you add ‘decoy’ choices, making the others (which you want people to pick) look better in comparison?

And the example is

Would you choose the $79.88 option here, when the other two offer you a free gift AND save you slightly more money?

That is great and widely used pattern in sales and marketing. My strong believe that management and leadership is of the same nature. Sales and marketing techniques work perfect here.

You should use this pattern every time you propose something to your client, boss or subordinates. If you did a decision and want to implement it you can either force a decision or sell it.

If you force your decision then you move in an autocratic way. That is a great way to show your power and it is definitely needed  sometimes. However, you are easy to blame. Any decision has some liabilities. And anyone can easily talk about how bad it is. As soon as there were no alternatives and you was the only one to decide, as soon as no rationale were provided, you are weak against this offense.

Alternatively, you can sell this decision. And this pattern is the way to do it. Find two more alternative solutions that are visibly worse than your decision. Try to design them that their liabilities point to the strongest points of your solution. And then ask another part to do a shopping. They will choose your solution, share the decision-making responsibility and will be glad for deep analysis of the situation and a number of options provided.

Disclaimer: Please keep in mind that it might not work in 100% cases and always have a back-up plan if incorrect option is chosen.

Inspired by: http://www.danlockton.com/dwi/Decoys

Pave the Cowpaths

Let’s take a look at architectural patterns. There is a well-known pattern of building paths in the parks. Author of design patterns calls it as Pave the Cowpaths and describes as:

Can you recognise the ‘desire paths’ of some of your users, and then codify them into your system, so others follow too?

As an example he provides the following story:

Example: In Tigard, Oregon, residents marked informal ‘neighbourhood trails’ they used on a map, so the city could prioritise ones to ‘formalise’.

A beautiful and clear solution from user experience point of view. However, the question is how does this pattern related to management that we are talking about in this blog. This is the pattern on how to build the right business process in tough to formalize environment.

Just imagine that you have to define processes on a newly created project. By its nature it has nothing common with you previous experience. It has no clear mapping to any classical management solution. And you have no clear vision in your head.

So, you can use Pave the Cowpath pattern. Just let the project live on its own. Define no processes. As you understand in a meanwhile a set of informal business processes will naturally appear. So, it will be the high time to formalize them.

Surprisingly, you might get a brilliant and clear solution. However, usually you get something strange and a bit messy as a result. Whatever you get, you have something to start with. You can polish, improve and redesign the processes but you will have them at least.

Moreover, you will get two guaranteed benefits that are the worth ignoring all the liabilities of this method. First of all this approach does work. Your artificially defined process didn’t block the job. And the second benefit is that this solution is absolutely organic. It has no pretty but useless additions from a management theory. You get the straightforward solution for your exact case. Isn’t it the process you where looking for?

Disclaimer: From the first sight it looks like oriental wisdom about sitting on the river bank and waiting for the corpse of your enemy. Strategically it is exactly the same. However tactically it isn’t. Please, don’t think that you should do just nothing and you’ll get the result. You must be part of the process, you must participate in building it. Do your job as you usually do. The only thing you should not do is to define the process until it is clear and proved to be working.

Inspired by: http://www.danlockton.com/dwi/Pave_the_cowpaths