Web development in 4 simple steps (kinda')

All web sites have a purpose and goals. Based on those, an Interaction design (IxD) can be created to specify how the site should work. Graphical design build on the IxD to define how the site feel and look. Implementation then actually make it work.

My IxD method, as outlined elsewhere, is based on the problems and issues that the site owner and visitors encounter. Together with pattern languages and user testing, a prototype (often on paper) is created.

In graphical design, color and shape are used to further the goals of the IxD. Relative importance of elements, relationships between elements etc are communicated via graphics. The grahpical designer is also in charge of creating a visual identity for the site. That the identity is suitable and polished is important–studies have shown that the visual design of sites greatly impact visitor's confidence. While designing, IxD issues will likely come to the surface and will need to be addressed. Delivery is often in the form of user tested digital prototypes.

Implementation is of cause the stage where the site is built, both on the front- and back end. During the build phase several IxD and visual issues will surely be discovered and will need to be addressed. Since the IxD has been done thoroughly the issues will likely be small and easy to overcome. After user testing the site is ready to go like and the circle starts again.

Am I reeeally needed, and if so, how much?

Which design tasks need Interaction Design knowledge to be properly solved?

1. If the task has been solved successfully before by the project group, they should solve it again. I.E. already done == do it again.
   
2. If the number of possible interaction related misfits in the task is small, or the possible misfits are almost irrelevant, the project group can probably handle them themselves. I.E. simple problem == simple solution.
   
3. If the task at hand has interactive elements that are difficult to get a grasp of (I.E. has a large number of possible misfits) and thus the solution is not obvious, specific knowledge of Interaction Design has great value. I.E. complex problem == IxD useful.
   
4. If previous attempts at solving the problem has failed, IxD might help. I.E. repeat failures == IxD to the rescue.
   

Once the need for IxD has been established, the question turns to: how much resources will be needed? The answer, of cause, depends on project scope (I.E. the number of possible misfits to take into account) but it also depends on how well the design should fit – sometimes even a large project can manage with a rather skimpy design.

Possible steps in my work include 1. interviews with the client, 2. interviews with their customers, 3. discussions with the project group, 4. own contemplation, 5. analysis and hierarchy-creation, 6. pattern reuse, 7. pattern creation and 8. pattern synthesis (to create the final form for task). Steps 1, 2 & 3 can be skipped, steps 4 & 5 can be rushed, step 6 cam be maximized at the cost of step 7. But some contemplation, analysis, pattern creation has to be done and pattern reuse and the synthesis has to be allowed to take it's time.

Prototypes of Design Patterns

I am reading Todd Zaki Warfels excellent book about prototyping and realized early on that I need to use prototypes as a compliment to functional diagrams for documenting design patterns in the misfits method.

When the method has produced a tree of misfit groups, the task is to find design patterns that neutralize the misfits, I.E. that solve the design issues. Starting from the lowest level (the single misfit) I create (or reuse) patterns. Once the low level patterns are found, they are combined to form higher level solutions, eventually creating a solution to the full design problem. A visualization (only one level of misfit groups and thus also only one level of solutions are display, but there is often several such):


In interactive applications, the full solution should often be a prototype. My new realization is that some low level design patterns also benefit from being prototyped.

In Alexander's book, functional diagrams play the role of communicating the contents of the design pattern. The following is an example of a beautiful functional diagram:


This diagram depicts an abstracted summary of data about traffic flow in an intersection. The arrows indicate direction of the driving vehicles, the width of the line indicate the amount of traffic flowing in each direction. Therefore the diagram indicates which form the new intersection should take, I.E. the diagram can function as a guide when designing the intersection.

Abstract diagrams can often be used in software design, but I feel that prototypes can add communicative abilities to a pattern. Prototypes are made to be played with – experienced – whereas diagrams are static. I imagine using prototypes for patterns that are highly interactive and thus difficult to create diagrams for.

Below I have embedded a demo of a full design solution prototype. Could not find videos of prototypes for smaller design problems, but it is easy to imagine the below solution being made up of a multitude of patterns that could benefit from a prototype...

10/GUI from C. Miller on Vimeo.

The misfits method might create innovative patterns, but that's not important

Language divides reality and can never present the whole, real X (with X being any man made or natural object or system). Language also categorize and, together with culture, formalize the categories, thus making it difficult to discovery new ways of categorizing the world.

A design problem, as stated previously, is the gap that exists between a object/system and it's context. The gap exists because a number of problems, misfits, exist. Eliminating the misfits will close the gap and thus produce an artefact that fits it's context.

Design problems, when presented to me, are in some more or less significant way not already solved. If a good solution to a problem existed, I would not be needed. This means that my solution needs to be innovative and thus the formalized categories created by language will be a hindrance. I need a method that actively opposes categorization.

In my method, as described in an other blog post and heavily influenced by C. Alexander, I work hard to avoid labeling the groups of misfits during the analysis phase. The problem, of cause, is that any label I apply will be the name of a preexisting category and, since the category name is an abstract simplification of the object/system it represents, associating the name with my group of misfits will, almost unconsciously, limit my imagination both when reevaluating and reorganizing the groups and when finding patterns that solve each group's misfits.

So, once the tree of misfit groups has been laid out, the pattern work begin. Each group, starting at the level with the smallest groups, is matched with one or more patterns that solve the misfits in the group. The patterns are often illustrated with a functional diagram and might also be accompanied by a label and a description, but the most important part is to clearly show which misfits the diagram solve. This means that the pattern and the misfits are the key deliverables from the process, rather then labels/categories.

When working with the method my goal is to find suitable patterns that, when combined, solve the misfits between a design problem and it's context. The patterns can be new or previously described (for example the book Designing Web Interfaces contain fantastic IxD patterns). A newfound pattern, I.E. an original solution to a group of misfits, can be said to be an invention. However, whether the pattern is new or "old" does not matter as long as the pattern is a good fit. I.E. on the pattern level there is no value in innovation itself, any inventions that happen to be created are a mere byproduct.

When the groups on the lowest level each have one or more patterns associated with them, the patterns are combined, from the bottom up, to create the complete solution to the design problem. Since I strive to avoid formalized, preexisting categories in my analysis, the solution will most likely both fit the context of use and be innovative.

Misfits are my new best friends

Current Process Overview
In my post "Thoughts on IxD process" I outlined the following as a good base for creating interaction design deliverables:

1. Understand the client — products, goals, market as well as the problem they want solved
2. Understand the client's customers and users
3. Clearly articulate the client's central process(-es) from a user perspective
4. Create concepts
   
5. Prototype and create reusable deliverables – material and immaterial – together with the client

The wonderful world of design patterns
I have recently finished C. Alexander's seminal book "Thoughts on the synthesis of form" in which he outlines the base of what was to later become "design patterns". (I also have Alexander's book "A Pattern Language" but have not started it yet.)

A quick note: Alexander speaks of the design of a new tea kettle as being a "design problem". I will use "design task" from time to time to refer to the assignment itself.

In the book Alexander highlights that creating a form based on a design task is actually the same thing as and understanding the context of the design task. Only when we start to understand the context can we create a form that fit the context. Also, when designing we gain new knowledge of the context – questions that arise during the design work will need to be answered and thus make us understand the problem's context better.

Alexander discuss misfits as being more appropriate to use in the design process then requirements. Misfits between a form and it's context are often easy to spot, easy to articulate and often even part of the initial design task: "Our web site does not sell enough gadgets", i.e. there is a misfit between the form (the site) and it's context (what customers want and act).

The start of the process for Alexander is to find all possible misfits that can occur between the form and it's context (including the ones already solved by existing products). Misfits should be analyzed to see if they actually are a unit of several smaller misfits. For example "Can not find items in the shop" can be divided into "Items lack meta data", "Search facility is missing", "Navigation items are not labeled according to the user's mental picture of the domain" etc, many of them then subdivided themselves. The misfits that are found often interact. In a sales site the possible misfits A: "Check out takes a long time" and B: "We can not ship without knowing the address of the customer" interact in a negative way – making one better can negatively influence the other. However, other misfits, such as C: "Available color options for items are not displayed" does not interact with A and B.

The misfits can be divided into groups based on which ones interact. The groups can be paced in a hierarchy – a tree – with the full design task ("Our web site does not sell enough gadgets") on the top and branching from that are the different groups of misfits all the way down to the misfits that can not be divided further. Only actual problems that can occur are included in the tree – if intuition tells us that a problem would not really occur, then it shouldn't be in the tree.

Starting from the bottom of the tree one then create a design pattern that, as far as possible, neutralize all the misfits in a specific group. The pattern can often be illustrated as a functional diagram – an illustration that includes both basic form and interaction. The lowest patterns are combined to create the upwards patterns all the way up to the full design diagram which solve the full design problem.

By modularizing design like this:

• the interaction between the created form and it's context is made clear during the process
• thus, it becomes easy to share ones reasons for design decisions (since there really are reasons for the decisions — not so common in web design)
• each design task becomes small enough to be grasped fully by the designer
• future upgrades to the form becomes easy as new problems can be introduced and only the patterns that interact with that problem should be changed
• creating a better version of a design pattern does not influence other parts of the system
• created design patterns can be reused if the same (or a very similar) combination of problems occur in an other project

Synthesis
When incorporating C. Alexander's wonderful work into my process, the following new process appear:

1. Understand the misfits that can occur in the design task. Tactics: discuss with client about their market, position, products etc, discuss with the client's customers about which misfits they find between their needs and the client's and the client's competitors products, have the designer and the development team think about possible misfits. (Step 1 & 2 in my previous process.)
   
2. Subdivide the misfits, find their relations and create the hierarchy. (Step 3 in my previous process.)
3. Create or reuse design patterns / diagrams that solve all misfits in each group, to create the final solution to the design task. (Step 4 & 5 in my previous process.)

Well designed sites

I was recently asked, by a recruiter, to name a few sites that I think are well designed. This is my answer:

To me there are lots of ways of defining design. Purpose, Content, Interaction and Decoration are a few of many design aspects.

http://www.etsy.com/ — Etsy has accepted the noble quest of creating a global market place for handicraft. They thereby work to increase the interest in unique, handmade products (which is usually good for the environment) and also work to make it possible for more people to live off their creative enterprise (which is good for the individual and society). They have created a number of ways to explore the thousands of products on the site and they engage sellers to take ownership of their shop within Etsy. The site's decorative elements are also well crafted—they set the focus on the products. Over $20 million has so far been invested in Etsy by Union Square Ventures, Accel Partners and others.

http://wave.google.com/ — I have one of the preview screen shot from Wave pinned to my wall at the office. I have not been able to use the service myself yet, but from what I have seen the wave team seem to be working hard with all the details that create good interaction. Both large aspects such as real time updates in conversations and personalization of the interface and details such as panel scrolling seem meticulously crafted.

http://www.gourmet.com/ & http://www.wired.com/ — Both of these Condé Nast sites are beautiful, useful and valuable but above all else they manage to engage my interest thanks to the use of different types of articles and (restrained) variation in layout and presentation.

http://www.drudgereport.com/ — Perhaps the worlds most poorly styled web site. But the fact that the Drudge Report has two to three million unique visitors per month and over a million dollars of profit per year despite having only two employees make the site excellently designed.

All points in a flow where not created equal

Jesse James Garrett's Visual Vocabulary is an excellent resource for creating flow charts. There are of cause also other diagramming conventions such as UML and Entity Relation diagrams, but I often use JJG's for my flow charts.

One thing that many vocabularies lack is a way to specify that some parts of a flow are more important then other parts. We need to focus our design efforts on the parts that add most value and we therefore need to be able to communicate the relative importance of different flows and even of different points in each flow.

The need to represent different importance in flows became apparent to me after a recent discussion with a client. The client is creating a system where customers of physical retail stores can go online to get access to services that enhance the shopping experience. I.E. they are enhancing physical retail by creating valuable online services.

The client of cause have a lot of flows that need to be outlined — for example finding and choosing which services to use, setting up services and daily use flows — but one of the most important ones is the flow that starts in the store with the customer getting info about the service. That flow, the discovery and sign up flow, will be the single most important one for the customer's first year.

When I lay out the different flows I do of cause only add as much detail as is necessary to the charts, which is something JJG clearly states as a necessity in his vocabulary description. So, already in the vocabulary there is a provision about only including what is important. However, the flows also need to be complete — that point A of a flow is less important then point B might not mean that point A does not need to be included in the graph.

My solution to the issue is to use color to depict differences in importance. Color after all has an innate ability to communicate importance — orange is generally more visible then light blue. In order to capture the power of color without over loading the graph, i often use hues. darker hues mean higher importance. Which color I use depends on my mood as well as the client's graphical identity.

Some examples:
The flow on the right is a standard Visual Vocabulary flow, on the left I have indicated that point B is the most important one in the flow, with C being slightly less important and A & D least important.

Here I have indicated that the choice of B or C is the most important part, with B being the preferred choice (preferred by a combination of the customer and my client). The graph could for example represent the decision of whether to pay by Credit Card or via PayPal, with Credit Card being the preferred choice.

The careful addition of color to flow charts to depict importance can enhance the communicative ability of the chart.