Showing posts with label great design. Show all posts

Design sessions: why and how?

A design session is used to focus on one or more design items to achieve business objectives with a group of designers. This technique could radically improve the dynamic of your team and the outcome of your project. The technique is best used when you have a three or more talented developers. 




10 reasons to conduct design sessions 


 1. Keep the team engaged and motivated
 2. Tap into the creative potential of the team
 3. Bring the team together on a decision with a common understanding
 4. Separate the designer from the design. You are not your design
 5. See with new eyes
 6. Learn from each other
 7. Close gaps (reduce distance between team members)
 8. Keep it simple
 9. Improve and simplify your process
 10. You think that you know it all


How to conduct and structure effective design sessions?














Here is an effective way to conduct and structure design sessions for your team.

How to Conduct a Design Session
A design session usually consists of two to three design items to help reduce time and consolidate our moves. A design item typically takes about 15 - 20 minutes. A design session should separate the “what we want” from the “how we want to do it.” It provides a venue to consider alternative solutions that could be simpler, clearer, easier, more secure, and more extensible.

Session Goals
The goals for the design sessions are to be…

    Healthy
        Encourage and allow others to contribute

        Be respectful

        Make your point

    Efficient
        We need to quickly understand, justify, and agree on an approach (the how)

    Interesting (not boring)
        Innovative solutions are a side-effect

What’s in it for you?

    Your idea gets used in an area that makes a difference

    Learn from others

    Gain a common understanding

    Have fun 

Attendance
Attendance is optional. There are probably a few different reasons to join a particular design session:
  
    You are passionate about it

    It directly impacts your work

    You are interesting in learning more about a particular area


Design Item Template


 Description: {Describe the problem statement}
 Alternatives: {List out alternatives provided by team with pros and cons}
 The Action, Next Steps (such as a spike solution), or Decision
 Rationale:  (A is important, so we chose B, accepting downside C): {There is always a downside; no decision is perfect}


Challenge Questions



Can this be deferred?

Is this the right item to consider?

Is there a way to simplify the problem/solution?

Does the item imply the what we want to do?

Does this help us deliver on-time?

This same format can also be used for process items.

Closing


The results of these sessions should be kept in a journal. The journal can be quite helpful to review decisions and to stop history from being rewritten. I have used this technique with bigger teams  including the redesign of www.bmwusa.com. The journal should be comprised of notes for each design item (design item template) and the overall structure described above.

Often, you will still need to make a decision to resolve a team deadlock, but by using the design session technique, there will be fewer deadlocks and members will be able to accept and follow the direction.

These sessions can be fun and effective. Team members want more of them. One key to success is to have the following team values: respect, collaboration, communication, and simplicity.

I would like to know what works for you. Is your team engaged or zoned out?

Enjoy.

Screw best practices and dogma

The term "best practice" is naïve, condescending, and quite dangerous. Why? Because it implies it can get no better and used regardless of your context or situation. You (and your team) live in a temporal context. Given your context, some practices are helpful and some are harmful. If you think about it, best practices do not even exist.


What should you embrace instead of best practices? Certainly consider practice patterns. A practice pattern is a practice that only makes sense in a particular context for a reason. Know your context and your practices will become clearer. The same is true for design patterns and you would not blindly use a design pattern no matter the context.

Dogma

Dogma is a set of principles laid down by an authority as incontrovertibly true.

5 problems with dogma (and principles)
1. Like best practices a design principle leaves no room for improvement and only makes sense in a context.

2. Combining design principles often works against your real and honest goals. 

3. Design principles are often in conflict, which can only increase complexity. 

4. Design principles come with a downside. This also reveals the truth about dogma: dogma lays down negatives as incontrovertible truth.

5. Design principles that worked in the past will not necessarily work in the future. Dogmas eventually collapse.


Why is dogma even more dangerous than best practices?
Dogma is even more dangerous, because dogma is much harder to refute, and teams can base even more value on dogma since it is an entire set of principles driving an entire architecture. Challenge one principle and you challenge the dogma and architecture as a whole.


"Don't be trapped by dogma --which is living with the results of other people's thinking. Don't let the noise of others' opinions drown out your own inner voice."

Steve Jobs (1955 - 2012)



What should you embrace instead of dogma?
Simply embrace design rationale and empirical data:

      A is important, so we chose B, accepting downside C.

Design Teams
Design teams can easily be locked in best practices and dogma. These often times divide a team in dysfunctional and irrational ways. Blindly following the dogma while losing sight of core goals.

Empirically, I have seen some of the most successful (and profitable) teams refute best practices and dogma, so there has to be something to it.

The main point: any design team should challenge best practices and dogma. As Alan Kay said, "Point of view is worth 80 IQ points."

In my view, best practices and dogma do not lead to great design  more often, they lead to poor over-abstracted design which can be even worse than an under-abstracted design.

Enjoy.

Fall in love with your work


"Once you decide on your occupation, you must immerse yourself in it. You have to fall in love with your work. Never complain about your job. You must dedicate your life to mastering your skill. That is the secret to success and is the key to being regarded honorably."

"All I want to do is make better sushi. I do the same thing over and over, improving bit by bit. There is always a yearning to achieve more. I'll continue to climb trying to reach the top, but no one knows where the top is. Even at my age after decades of work, I don't think I have achieved perfection, but I feel ecstatic all day. I love making sushi."

Jiro Ono - Jiro Dreams of Sushi

Perhaps, love does lead to great design. Dreaming should be encouraged. Enjoy.

Two reasons why you will like Windows 8 store apps even on your desktop and laptop

For more than a year, I have been thankfully using a Windows 8 tablet that was given to attendees of build last year. Since then, I have been using the tablet as both a consumption and creation device—and even as a +95% replacement for my Moleskine notebook. Windows 8 preview editions have been very stable for me throughout the process including Visual Studio 11 (2012).

Two reasons why, in my view, you will even like to use Windows 8 store apps on your desktop and laptop:

1. Reduced Friction
Traditional window management tasks such as moving, sizing, restoring, minimizing, maximizing, and closing are excise. This excise creates friction in the user experience. It may seem small, but it takes work to even get to the point where you can accomplish a goal. Great interfaces get out of the way and window management, often times, gets right in the way.  

2. Improved Focus
Multi-tasking is a fallacy. Many studies done including a recent one at MIT conclusively show that what we commonly consider to be multitasking actually occurs in a sequential, not simultaneous manner (Source).  All of us should focus on a single task at a time. People do fuse with their toolscognitively at least; so, proper tooling can make a big difference in our behavior and productivity.

In my view, using Windows 8 store apps can help improve your focus by forcing you to focus on one or two apps at a time. This style will just help us create better apps to help people be more productive overall.

"But I need to monitor my email and switch quickly between applications," you say.

I agree. Sometimes there is no substitute for a multi-monitor multi-window environment; however, Windows 8 does enable a quick context switch without having to re-launch the Windows store app. Quickly spin through your cognitive context of 5 to 7 things and start new ones. With simple gestures, you can quickly switch between contexts, dock, or close an app. These simple gestures also work well with a track pad or mouse. If you had to re-launch the app every time that you did a context switch, that too would create friction and excise.

With the focus on the content and not the excise and chrome, the experience can be much better.

Conclusion
My belief is that you will enjoy Windows store apps even on a laptop and desktop. Now, as a developer, I spend a lot of time using the traditional desktop with Visual Studio and with many other apps.

This only the beginning—a 1.0—of a shift in using Windows without windows. Even with a multi-monitor desktop, I use Window Store apps often—and even trumps over some traditional desktop apps. One example, I prefer using the Windows store app tweeTRO over any other desktop or web Twitter client.

Imagine making the same gestures without touching the display or a mouse—in front of a TV, game console, or even desktop. I can imagine a day when we will develop code with our hands and bodies not just our fingers (do not worry: computational thinking is still required).

We will fuse with Windows 8 in many other ways beyond the keyboard and mouse.

In my view, the Modern UI style (formerly known as Metro) is great design. Windows 8 is certainly not perfect and granted not everyone will enjoy it as much as I do, but my belief is that sooner or later you will too.

Enjoy.

How to identify an under-abstracted design?

What is an under-abstracted design?
A design can be over-abstracted in some areas and under-abstracted in others. Just as over-abstracted designs can have too many abstractions and classes, under-abstracted designs have too few to handle interactions and satisfy requirements. Intuitively, it might seem that an under-abstracted design would be good, easy, and simple, but the real problem is that an under-abstracted design is difficult to understand, change, and maintain. Ironically, the result of under-abstracted design is high complexity and excessive amounts of code.

The good news is that is easy to identify and address these areas. Once addressed, your confidence and development velocity will increase; and more importantly, you will be able to satisfy new business needs.

What is the best indicator of an under-abstracted design?
In my view, high complexity is the best indicator. Not only will it help identify under-abstracted areas of your design, but real problem areas within your codebase.

A simple and long standing complexity metric is cyclomatic complexity. Cyclomatic complexity (or conditional complexity) is a software metric developed by Thomas J McCabe in 1976. Basically, it is a measure of the number of control flows with a method, function, or module. The metric is computed by counting the number of decision points + 1. For a more formal definition, check out McCabe’s original paper: A Complexity Measure.

With Visual Studio Pro and above, you can identify these areas within a couple of minutes even if you are not familiar with the codebase. To do this in Visual Studio, use the following menu item: Analyze->Calculate Code Metrics for Solution. Visual Studio 2012 allows you to export the metrics to excel so that you can more easily identify the methods that have the highest complexity.

How to evaluate risk by cyclomatic complexity?
There is a strong correlation between defect density and high cyclomatic complexity. Below is a risk evaluation for methods as defined by Software Engineering Institute (SEI):

Cyclomatic Complexity Risk Summary
1-10 Simple, low risk
11-20Moderate complexity, medium risk
21-50Complex, high risk
51+Untestable (Very high risk)

Why is using cyclomatic complexity metric important?
In short, complicated methods and classes are tough to understand, difficult to test, challenging to debug, and usually require vast amounts of time and attention to maintain.

To understand code, it must be readable. The concept, although not the method, is somewhat similar to that of general text complexity measured by the Flesch-Kincaid Readability Test. Methods with lower cyclomatic complexity are much easier to test.

When modifying a method with 50+ cyclomatic complexity, chances are very strong that you will introduce at least one defect while either adding a new feature or fixing another defect.

Other good indicators…
Here are a few other indicators to help identify under-abstracted design:
  • Duplicate code
    How to identify: In Visual Studio 2012, you can identify duplicate automatically using the following menu item: Analyze->Analyze Solution for Code Clones
  • No business, service, or data access layers
    How to identify
    : All the code is in the User Interface layer represents a lack of “separation of concerns”; that is, where all of the business logic, security, data access is performed in the user interface layer. This indicator might be obvious to many, but is not followed even more. Even if your design has a clean separation of concerns, there can still be high cyclomatic complexity in the business and UI layers.
  • Too many methods and members per class (Large classes)
    How to identify
    : Look for large classes in terms of Lines of Code (LOC) and perform manual inspection. Look for classes that are doing more than one thing. The number of methods and LOC can be subjective, but here is a discussion on stackoverflow of what that number might  be.  
Conclusion
Under-abstracted design is definitely not great design. In my view, cyclomatic complexity is a simple, well established, metric that can identify under-abstracted areas of your design and codebase. The irony: under-abstracted design results in high complexity and excessive duplicate code.

Remember, complexity is our common enemy so keep fighting it.

Upcoming: How to advance an under-abstracted design?

Enjoy.

Why has Microsoft's Metro design language captured the essence of modern interface design? 5 key elements.

What is Metro?
Metro is a typography-based design language. Metro style is guiding a new unified experience on Windows 8, Xbox, Windows phone 7, and can even be experience on Windows 7 in the form of Zune, and Windows Live. A design language, such as Metro, is used to guide the architecture of a group of products by capturing the principles and elements of a design approach into a single concise set. Metro gets its name from way finding systems found in metropolitan areas such as airports, subways, and urban areas. Metro gets its inspiration from modern design (reductionism), Swiss design (clear, honest, and beautiful), and motion design (the force of time—the way we experience the world).

In my view, great interface design gets out of the way and Metro gets out of the way by focusing on the content. Metro has captured the essence of modern interface design based on five key elements. 

The 5 key elements

1. Typography
Metro is founded upon clean beautiful typography.
Proper color, weight, and size can help eliminate all of the chrome, color, and graphically over manipulated design elements. Even hierarchy can be easily and cleanly shown with just typography. It is not just about typography, it is about the content.

2. Authentically Digital (Inversion of Focus)
With Metro, the user is not focused on the chrome elements such as menus, buttons, panels, and color images with in the chrome that are shaded, the user is focused on the content.

With Metro, there has been an inversion of focus. Great interfaces get out of the way.

Metro is not just about typography, it is about content. By removing all chrome, it helps put the focus on the content whether it is text, images, or video.

With a modern interface, we do not need chrome to indicate what can be pressed or manipulated. Now, the content can be manipulated. After 40 years of WIMP based interfaces, we all know how to use a computer.

3. Spacing with thoughtful reduction
Spacing is important—and made possible with the removal of all of the chrome and over-manipulated design elements. Even if there is room for another button or feature, it certainly does not mean that you should add it. In fact the opposite, you should challenge every element. It takes focus. From a visual design perspective, no longer do we need chrome on top of chrome nested in chrome.

4. Motion (fast and fluid)
Motion, used properly, can create a fun fluid interface. It brings the experience to life. In my view, motion is more important than graphic design. Metro uses animation in the right places and for the right reasons:

     Delight the user
     Simplify the task
     Hint towards interaction
     Provide a feeling of moving forward
     Respond to user behavior
     Teach the user how to interact

5. Asynchrony and intelligence
It is easy to overlook the importance of this element just as Steve Jobs admittedly missed object-oriented programming when he visited Xerox Parc where he became inspired to produce the Mac. It is easy to miss Async Programming in the same way.

Asynchrony helps make an experience fluid.

Closing
Originally developed by Xerox over 40 years ago, the traditional desktop metaphor is a bit tired at least from a design and metaphor perspective. In addition, analog design elements and metaphors are not what digital design needs today. We know that live elements can be tapped or swiped. We do not need 10 pixels of shading and blasted with color inside of a box that is further shaded wrapped in a panel with indentation—you get the idea.

There is a design revolution at Microsoft. In my view, Microsoft is leading Apple at interface design—I know sounds like heresy. Metro and Windows 8 are not perfect, but the direction is game changing. It is easy and safe to jump on the Apple design bandwagon because mostly their designs are great. But I am not afraid to point out that Apple is not the only company that is doing great design and appreciates great designers. Now, it seems that almost every company cares about great design. Design matters.

In my view, the Metro design language has captured the essence of modern interface design. Metro is modern and clean—fierce reductionism, simple, and fluid. 

Enjoy the pursuit

Great quotes from great designers

“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”

—Antoine De Saint-Exupery


“The architect should strive continually to simplify; the ensemble of the rooms should then be carefully considered that comfort and utility may go hand in hand with beauty.”

—Frank Lloyd Wright, 1908


“You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new.”

—Steve Jobs, 2005



What kills great design?

The killer is complexity. Complexity kills design, projects, products, and companies. Many teams struggle to produce version 1.0 of a product. Other teams can produce version 1.0, but within a few versions, the product is stuck in a quagmire of complexity—unable to move the product in a strategic direction.

Managers and stakeholders see it in the form of rising issues and inability to do anything new. Meanwhile, more distance is created between what you are and what you want to be.

Complexity is the true enemy for companies, teams, and developers.

How can you fight it?

1. Don't hire complexifiers: On the surface, they seem smart because they point out every possible thing that could go wrong or that you might have to worry about someday; with it comes a load of conceptual weight; complexifiers are people that create over-abstracted designs and make everything too complicated. Like a tick, once they have dug-in, they are difficult to get rid of because they have produced a pile of code that is not understood or modified easily. One way to identify complexifiers is that they tend to write a lot of defensive and complex code with no test cases.

2. Use simple design and embrace change: Always strive for simply design and use automated test cases to embrace change. Do not overdesign. You can't predict the future so be ready to change when the future changes—seems inevitable. The idea is easy: to change a simple design should be simple and you will be able to have trust in the system because you have a suite of automated tests to validate change. Reduce conceptual weight.

Be agile not just in development but also operationally. Windows Azure provides the best operational agility that I have seen so far.

3. Be a champion for simplicity: Do not add stupid features and do not let others kill your product. Don’t listen to your lizard brain.

The best weapon against our common enemy, complexity, is simplicity. It is a powerful form of Kung Fu.

One last thing: complexity even kills people: http://www.amazon.com/Fatal-Defect-Chasing-Killer-Computer/

Great design is not you

You are not your design. In order to achieve great design, you need to separate yourself from it.

Sometimes as designers we can wrap our entire self-worth into a single design or architecture. We become our design; any criticism about the design is a direct criticism about us. This just isn't right and leads to negative results. Besides, you are a lot better than a single design.

You might have become your design if…

   You feel that any feedback or criticism about the design is directed toward you

   You want to play it safe because you are afraid of what other people might think (also a sign that you are using your lizard brain)

   You feel that you can't change it

   You feel you can't improve upon it

   You have trouble moving on to other design projects

If you are your design, then you and the design suffer.

Here are six reasons not to become your design:

1. You will be happier: you won't feel like feedback on your design is feedback on you

2. Your design will improve: you will be more open to great ideas

3. Your design process will be open: if the process is open, you will incorporate better ideas; the design will grow and improve

4. You and your team will operate at a higher level: higher level teams  collaborate; being too attached to your design will create gaps

5. It will lead to success: others like working with objective designers

6. You can produce more designs: you are free to design if you are separated

I love working with developers and designers that realize this. In contrast, the few prima donna designers that I have worked with just cannot separate themselves at all from their own design which takes a lot of the fun out of the process.

To achieve great design, separate yourself from it. Give it a try. If you do, great things will happen. The earlier you practice this, the better it will be for your career.

What do you think? Do you have any examples or counter-examples? Do you have any other reasons why you should not be your design?

Be great and produce great designs—lots of them.

5 reasons that over defensive programming is not great design

#5: Too much time is spent making the code defensive
I have encountered some good developers that spend an inordinate amount of time putting defensive mechanisms into their code: hiding, sealing, protecting, checking, throwing, obscuring, and complicating. "I just need ten more hours to make this object inaccessible." And, "the solution is to make everything static."


#4: Too much complexity
All of this adds complexity. It adds surface, design and cyclomatic complexity. While there is a certain amount of essential complexity built into any problem space, each little bit of unnecessary complexity adds conceptual weight.

#3: Not as testable
The implication of sealing, protecting, obscuring, and complicating: code is less testable. One irony in all of this: these good but over defensive programmers never seem to write any tests.

#2: Inhibits change 
Defense driven development it is a different approach: one that does not embrace change albeit. You need simple, testable code to embrace change. This one could be #1. In some domains, the ability to adapt to change is the key to being #1 (and sometimes survival).

#1: It is hubris 
It is like saying, "I have thought of everything." You can't extend or modify this kind of code. Those that spend time sealing, protecting, obscuring, and hiding, are making it difficult for people to extend their code. There is no framework or open architecture. It is closed without being open. Realize: you can't think of everything.

Now, don't take this too far—in a way that is the point. A small amount of defensive programming is not only good, but necessary. But taking it too far creates too much distance.

At some point you have to score, so don't let your lizard brain get in the way.

Code is design. Over defensive programming is not great design.  

What is the killer benefit of cloud computing?

The killer benefit is business continuity. With cloud computing, businesses can improve continuity when faced with real-world events: acquisitions, bankruptcy of a vendor, escrow deals, loss of personnel, moves, growth, and others. This improved continuity helps increase velocity and momentum necessary for growth.

The reason: business continuity is a big deal to investors, stakeholders, and customers. They are the very people that drive these kinds of decisions. It will likely not be the CIO or Director of IT, but a customer that pushes you into the cloud.

Imagine that you are a small to medium-sized business and your biggest customer, a Fortune 50 company, wants to use your solution for their entire company. In this kind of deal, a software escrow agreement will not be enough; they will want your solution to be in the cloud. So that in the event that your company goes under, they can just take ownership. They acquire this virtual property as opposed to trying to figure out a mess of software and hardware that is hard-coded to a particular location with odd configuration and deployment.

Imagine another scenario: a company loses a vast amount of data because of hardware failure and did not notice that their backups had been failing for the past 6 months. Or a RAID 10 system is lost due to administrative error. By the way, evidently most arrays are lost due to human error. There are a ton of other scenarios like these that can hamper business continuity. The result of any one of them can be detrimental.

Cloud computing will also reduce capital and operating expenditures; also, likely to appeal to stakeholders, but business continuity is the killer benefit that will push companies into the cloud.

In my view, cloud computing is great design. What do you think?

Can command and control ever lead to great design?

No. At best, it can lead to good design but never great. Here is a quote that helps make the point from a wonderful book about how man made things are becoming more lifelike and life is becoming more engineered called Out of Control
"The USSR didn't collapse because its economy was strangled by a central command model. Rather because any central-controlled complexity is unstable and inflexible. Institutions, corporations, factories, organisms, economies, and robots will all fail to thrive if designed around central command."

From my view, there is nothing elegant or great designed by command and control. It cannot be great because it is not
sustainable. Can you provide a counter example? I am curious. 

The quote is from page 42. After locating the reference, I found that
Out of Control is 15 years old, but it is still a fantastic book. Leads me to another question: by what factor do great designs last?