pursuit of great design: design

Showing posts with label design. Show all posts

Here was a super fun project. The story guides you -- starting with a tour and then how we built it including the bill of materials, construction tips, and sourcing.

I, originally, did the design and blogged about it in 2011. It was a popular post, so I always intended to post an update, but decided to use a web-based Sway presentation instead. It brings it to life and is more effective way to show you around the lab.

My hope is that you find it helpful, interesting, and entertaining.

How to design your own your own deep work lab: https://bit.ly/DeepWorkLab

Why?
To support deep work. Deep work is valuable and increasingly rare. As Cal Newport says, "Deep work is performed in a state of distraction-free concentration that push your cognitive capabilities to their limit. These efforts create new value, improve your skill, and are hard to replicate."

Enjoy!

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.

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.

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-20	Moderate complexity, medium risk
21-50	Complex, 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.

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.

What is the next major paradigm shift?
In my view, the next major paradigm shift in software development will be asynchronous (or async) programming and design. It is our next paradigm shift because it helps alleviate pressures and follows a surprising progression. Only when we change the way that we program, does it change the way we design. When we significantly change the way we design—a major paradigm shift occurs. This change has been brewing for over ten years, but only now is it about to happen.

What is async programming?
Async programming uses asynchronous method calls instead of synchronous calls especially for potentially long-running methods. The idea: you make an asynchronous call and then provide a mechanism to run code when the result returns. Async programming is necessary for responsive browser, mobile, and upcoming Metro style apps that are mono-threaded as well as for intensive multi-threaded server applications. When all components are async, it can be fluid, natural, and resilient.

Why is async design the next major paradigm shift?
The main reason is that it helps satisfy a strong and growing need: to make use of multi-core processors and to make mono-threaded user interfaces highly responsive. In-browser apps allow only one thread. Async programming makes both possible. New mechanisms for async programming in upcoming C# 5.0 makes it much easier. Asynchrony dramatically affects design.

The shift also follows a surprising progression. Realize that for the past 50+ years, we have had stable high-level programming elements: data, functions, and threads; although combining them was a challenge.

Even though structured programming and design (SP/SD) techniques are still used today, before the mid 90's, it was the conventional or mainstream way to build applications. The problem: structured design treated data, functions, and threads as complete separate abstractions.

Today, object-oriented programming and design (OOP/OOD) techniques are the conventional way to build applications. Object-oriented programming and design combine data and functions into a single mechanism: the class or object.

Async Programming and Design (AP/AD) gives us a simple way to combine all three into a simple unified mechanism. An async object or agent consists mostly of asynchronous method calls. New mechanisms in async programming make it easy to combine data, functions, and threads.

These paradigm shifts (structured, object-oriented, and async) have gradually combined these high-level programming elements. Each paradigm shift has always started with changes to programming, and then to our designs. Only when it moves to design do we realize that a paradigm shift has occurred.

High-level programming elements in relation to paradigm shifts.

If this is truly the progression, then async programming will lead to async design. It might also hold true that async design is a natural evolution in computational thinking. Moreover, it provides an easy way to map to multi and mono-threaded applications and to avoid deadlock, latency issues, and race conditions.

Why is it about to happen?
It is about to happen because great mechanisms for Async Programming are about to become mainstream that will make it much easier. And once async programming becomes mainstream, then so will async design. Our designs are about to significantly change and a major paradigm shift will follow. This has been brewing for over ten years. Just as with structured design and object-oriented design, it took over ten years for it to evolve and become mainstream.

What are the implications?
Today, best of breed architectures consist of a directed-acyclic graph (DAG) of object-oriented components. Fully async objects or agents can help flatten this DAG of components reducing overall dependencies. Realize that most of today’s software architectures are probably not the best of breed.

Looking back, structured design led to some of the least desirable forms of cohesion and coupling. OOP/OOD led to much more desirable defined shapes of software. For me, the revelation at a time of uncertainty for the OOP/OOD paradigm shift was that it naturally led to more desirable forms of cohesion and coupling.

One of the key benefits of Async Design is that it leads to even better shape, and reduces overall dependencies. Flattening the DAG will be the required for ever-increasing architectural complexity. Great software design will, eventually, require software intelligence.

Asynchronous systems are radically different and will require new patterns, architectural viewpoints, mechanisms, and education. Unlike synchronous systems, asynchronous systems will not be halted like an assembly line due to a single point of failure or delay. Asynchronous systems will be even a truer reflection of the way a real company operates—like an organism—not an object-oriented an system.

A new category of software patterns will emerge. These new patterns will help us deal with more autonomy and system intelligence.

We will begin to design fully autonomous objects that consist primarily of async methods that leverage mono and multi-threaded environments.

Where can you go from here?
Change the way you program and it will change the way you design. Check out some of the resources below for more information on async programming for .NET.

You know you are close to crossing this chasm within your company or team when the last objection is performance. Unbelievably, functions were thought too costly for structured programming and dynamic binding was thought too costly for object-oriented programming. Once people overcome the performance objections of asynchronous methods, we will know that the industry is about to shift.

Soon, great designs that are fluid, intelligent, natural, and resilient will be async.

Where ever we go, make the most of it. If you do not enjoy programming and design, then you are probably doing something wrong.

Additional Resources
Async CTP (can be used with .NET 4.0)
Metro async/await
C# 5.0
C# Specification

The key is focus. You must find the essence of the product. You must deliver the key features needed—not all of them—just the essential ones. It requires focus because that is what people want and expect. People want the NUI (Natural User Interface) experience to be better, simpler, and to satisfy their goals in a simple natural way. Just because there is room for another link, gadget, button, or ad, does not mean you should add it. The friction that is created, conceptual weight, and maintenance usually don't justify it. It is just a different way of thinking. Simple, minimal, and beautiful—the attributes all apps should have. By focusing on what is important, you could even change your whole company. Focus leads to great design.

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: 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.

Seth Godin is a great bestselling author that really gets me motivated and inspired. I am definitely a part of his tribe. One of his recent memes is about the lizard brain in all of us. As he describes it, the lizard is a physical part of your brain, the pre-historic lump near the brain stem that is responsible for revenge, fear, rage and reproductive drive. The "lizard brain", really called the amygdala, is mostly the same brain that a chicken and lizard have. This brain is the one that developed millions and millions of years ago. This prehistoric vestige is no longer relevant because there are no more saber tooth tigers chasing us.

In order to do great design, you'll need to quiet your lizard brain. Artists usually know how to sooth or quiet the lizard brain, because art starts in the big brain (neo-cortex).

Your lizard brain might be in control when you...

are interviewing a peer that would be great for your company but your lizard brain feels threatened; Jim Collins argues that this is no way for a company to go from Good to Great
have a possibly great design but you are afraid people might find a flaw
need to do something that isn't in the manual
need to prepare a presentation for your customer or team

Once you realize that everyone has the same problem and it has a name, you are almost all the way there in solving it. And when you feel the lizard brain in control, then you are probably on the road to greatness.

In the this video, Godin targets our "lizard brain" as the source of primary doubts.

Video: Quieting the lizard brain

Here are a couple of posts about the lizard brain:

http://sethgodin.typepad.com/seths_blog/2010/06/amplifying-the-lizard-brain.html

http://sethgodin.typepad.com/seths_blog/2010/01/quieting-the-lizard-brain.html

Don't appease the lizard or you will be making the biggest mistake of all--you will always be trying not to fail. Failing is so better than not attempting, so make things happen.

Enjoy. I hope you find it inspiring.

pursuit of great design

How to build your own deep work lab

Design sessions: why and how?

10 reasons to conduct design sessions

How to conduct and structure effective design sessions?

Design Item Template

Challenge Questions

Closing

Screw best practices and dogma

Dogma

How to identify an under-abstracted design?

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

Why is the next major paradigm shift in software design about to happen?

What is the key to developing great mobile apps?

Great design is not you

5 reasons that over defensive programming is not great design

Quiet your lizard brain in order to achieve greatness

top

Tags