Pattern languages are a design tool used to describe a set of best practices for a given design-space. Pattern languages have been used for centuries in urban planning and architecture;  more recently they have been applied to software product design.

The earliest pattern books were created by the Roman architect Vitruvius wherein he describes best practices for siting buildings, proper arrangement of rooms, external ornamentation, fenestration, etc.   Christopher Alexander coined the term “pattern language” in his 1977 book that focused on designing buildings and ranged from the macro (regional planning) to the micro (interior window treatments).

Jennifer Tidwell started an early effort to catalog UI patterns online which resulted in her book Designing Interfaces.  Yahoo’s design pattern library is a popular site for Ux designers interested in pattern languages.  There are many web sites on UI patterns that can be found using Google.

My team is currently in the process of constructing a set of UI pattern libraries that will serve as the canonical design references for our entire product suite. Our pattern library is divided into two core areas:  Product patterns, and Visual patterns. The two libraries are linked to one another. The product pattern library details all of the core structural elements and behaviors in our products.  The structural elements display data, allow users to navigate, etc.  Behavioral elements deal with things like drag-and-drop, selection,  etc.  The visual pattern library deals with all of the visual language aspects in the products, e.g., colors, fonts, icon styles, layout, sizing, etc.

The product pattern library utilizes a wire-frame, gray-scale drawing style with lots of diagrams, and callouts to illustrate how each pattern works.  The visual pattern library utilizes high-fidelity, pixel-accurate drawings.   We created the two libraries so that we won’t need to rework all the images and diagrams in the product pattern library whenever we update the visual language.

We expect to achieve substantial productivity gains and process efficiencies using the pattern libraries.  Each product specification we create is linked to the pattern libraries.  Rather than having to describe all of the behaviors for a table or tree control in the spec, we can simply illustrate the design, provide a minimal description of the strutural, behavioral, and visual elements, and include a link to the corresponding pages in the pattern libraries.

As my company and the Ux team scale into smoothly-functioning global organizations we will be able to coordinate the work of designers, engineers, quality assurance, and documentation teams around the world using the pattern libraries as a key reference and communication tool.

I’ve recently been thinking about how to better blend Agile development and User Experience Design.

Given my education in Industrial Design (ID), that was a natural first place to see what models might translate.  Yes, there is all the prototyping, mockups, and rendering that are highly applicable to any software project.  However ID doesn’t really do it because it is classic “waterfall-based” design approach.  There is no other choice when designing for manufacturing on an assembly line.  Everything has to be defined up front in order to build the tooling and stamp out the parts.

Next, I looked to Architecture (the building kind).  Although I’m not an Architect, nor do I have Architectural training, I helped to re-design the kitchen and master bedroom/bathroom of my house. I also served as general contractor on the kitchen remodel.  Building buildings is a lot more like software development than ID.  You try to define most things before construction begins, but there are always quite a

number of things that can only be tackled as you get to them in the construction process.

I know the big deal with Agile is that design, implementation, testing, etc. are all supposed to proceed in parallel.  But IMO this is an immature perspective on requirements and design. Agile development was created by software developers, not designers.

What I’ve come to strongly believe in through repeated exposure to Agile development projects is that Agile development must be proceeded by some iterations of Agile requirements and design.  This needs to happen BEFORE any coding actually begins.  Prototyping during the requirements and design phase is OK, but trying to create production-code and test it is a mistake during this phase.

I don’t believe you need a lot of these design iterations before coding starts.  You just need to ensure that you’ve:

1. Got the right requirements
2. Defined the big pieces of your product’s information architecture, navigation model, and the key surfaces
3. Validated your design concepts with users

Once you’ve gotten the big design pieces reasonably defined; the traditional, synchronous work of Agile can begin.   Using this approach allows the design details to  plug into the larger design architecture more easily and rationally.

A product management colleague recently asked me for a concise explanation of user experience design.  Here goes…

1. Product UI designs should be based on real-world use cases & customer needs
2. There are multiple possible solution spaces for any design problem—each one has relative pros & cons
3. Design assumptions & decisions should be VALIDATED with users (and your sales team) BEFORE “beau coup” dollars are spent on implementing them
4. This point is somewhat orthogonal to the above, but is important if you are designing a suite of products;  in this case you should be leveraging design patterns & standards across those tools in order to ensure transfer of training, ease of learning & use, and coherence within the suite

This doesn’t mean that Ux design is easy or trivial, or that by simply following these steps you will end up with good products.  However if you don’t follow these steps in your process you can pretty much be assured of ending up with products that suck.

The concepts for this post were taken from an interview given by Erica Payne on KPFA radio. Payne holds an MBA from Wharton School of Business and is founder and principal of the Tesseract Group–a boutique consulting firm that specializes in strategy and communications for foundations, philanthropists and organizations engaged in the public policy arena.

Payne’s interview focused on the US presidential elections of 2008. She described politics as essentially a supply chain problem. Payne went on to describe how we ought to conceptualize political change through the metaphor of the skipper, the boat, and the river. Her message has a direct application to User Experience teams.

The skipper is the Ux team leader. The skipper is responsible for charting the course of the boat, steering it, and ensuring the well being of the crew.  The skipper must be attentive to whether the boat is well maintained and cared for.  They are the “face” of the Ux team to the broader company.

The boat consists of the  Ux team members, the artifacts the team produces, and the internal processes used to produce those artifacts. The skipper is nothing without their boat.  The Ux team members (the crew) are important representatives to other teams at the company–most typically at the project level.

The river is the company’s culture–how it approaches design, production, and marketing of its products. Shaping and changing the nature of the relationship between the Ux team and the company’s processes is key to ensuring the Ux team’s ongoing success.  The Ux team must be constantly attentive to how its activities are leveraged and plugged into the overall activities of the company.

Patrick Blanc–a Parisian botanist–developed the concept of integrating vertically oriented plantings directly into unusual architectural settings. His book, “The Vertical Garden, From Nature to the City” is profusely illustrated ( I thumbed through it for about an hour this afternoon at the bookstore). It begins with many examples from the forests he studies. The next section features a discussion on how certain plants will naturally grow on architectural surfaces (most notably in the tropics). The final section is dedicated to Blanc’s many installations throughout the world.

Musee du quai Branley in Paris

The installations were strikingly attractive, rich in color and texture. The scale of some of these were immense. While most of us have seen ivy-covered walls and mossy walkways, what made these so interesting for me were the variety of the plantings, and their incorporation into unique architectural environments distinct from gardens. Blanc turns what would normally be bland architectural surfaces into living, growing garden-spaces.

The vertical gardens are created by attaching some type of felt to a PVC framework. Various species of plants capable of shallow rooting and vertical orientation are then stapled to the felt where their roots take hold. A network of pipes and tubes carries mineral-rich water to the plants. According to Blanc, his interest in gardens, plants, and life in general date to a boyhood fascination with aquariums and aquatic plants.

Blanc has developed a technique that allows architecture to become garden. Can you imagine an entire city or city street growing up like this? How would it feel to stroll, shop, live, and have coffee in such a luscious blend of the natural and the man-made?

Vertical garden on a storefront

I love it when a designer is able to fire up my imagination like this. I haven’t been able to stop thinking about how cool it would be to grow a vertical garden on an ugly section of backyard fence I’ve been neglecting for quite some time.

Quantas lounge

I recently posted the following question to a group of Ux professionals: What is the single most important activity that a user experience group can do to increase its effectiveness and influence? I asked everyone to draw from their real-world experience, NOT theory or ideals.

There were a number of thoughtful, practical responses…

Jeremy Ashley said:

1. Take time to truly understand what your company, organization, executives, and program managers need from the user experience. Accept that they know their business, and your role is to help enable that.

2. Hire in skills beyond the traditional designer/usability engineer roles. Hire PM’s to help effectively communicate with the outside PM and dev teams, as well as support project management. Hire developers to help understand real world implementation issues and opportunities. Hire marketing specialists to help evangalize, promote, and train both within and outside the company

4. Determine your plan and follow it. Modify it only after significant discussion with senior staff to ensure you examine all angles and possible outcomes. Do not get distracted by ego, politics, or emotion as you will waste your time reacting rather than driving.

5. And finally….The only way to impress your boss is to DELIVER

Steve Fadden said:

If this is a group with NO UCD experience whatsoever, I think nothing beats a good usability test. Not so much for what it tells you about the product’s usability (though that’s always helpful), but because it gives you a lot of “bang for the buck” in terms of access to information:

• You gain access to a real or potential user who comes in for the test, so you can talk to that person about her/his demographics, skills, expectations, work environment, key tasks, performance measures, and so forth.
• You gain the ability to observe a user trying to use your product. This can be especially value if you can
• get other members of the team to observe, as it opens their eyes and increases buy-in for more UCD
• activities in the future. You gain the knowledge about key problems with your product right now. So you have the opportunity to highlight these problems and address them in your work (it also provides a way to prioritize the problems from a user’s perspective)
• Last but not least, you can get ideas for solutions from the end-user’s perspective. It’s not the only solution path, but a valuable one to ensure that is represented in the iterative product development process.

If it’s a group that’s already doing some usability evaluation (with real target end-users) as part of its process, then I think the next beneficial activity is some form of observational activity of the end-users in their context of work. This might be in the form of simple site visits or complex contextual design activities, but the important part is to ensure that people on the team are able to observe a number of end-users in their ‘natural environment,’ interacting with the the people, systems, and resources that are common for the work or activities being performed.

Paolo Malabuyo said:

Make sure that the culture of design and user experience is explicitly supported from the top. Unless executive management cares about user experience, it’s going to be an uphill battle throughout. Grassroots organizational support can only get you so far.

For me, choosing where to go next had a lot to do with this. After 12 years working for 3 large companies (IBM, Oracle, and IBM) I’ve had a lot of exposure where the culture is not one of design but of engineering. Trying to change a company’s DNA is very difficult, and without that change happening from the top I don’t know if it’s going to happen in a deep and sustainable way.

Any cultural change is going to be seen by an organization/organism as either an infection or a mutation. In engineering cultures, you want design culture to be a mutation; unfortunately, the organization will react as if its an infection, and the white blood cells will do everything in its power to kill it. It will not be a mutation unless there is support from the top.

In my current company I’m able to have that support and explicit activity from the top. In my previous job at Microsoft, the results of some of these activities can be seen in the Xbox 360 (not to be confused with the current hardware failure problems!) user interface and capabilities. Time will tell whether what we were able to do will take hold as a successful mutation or will eventually be eradicated as an infection. My fear is that it will be as long as top management doesn’t explicitly support and prioritize design and user experience.

Michael Arent said:

Make sure the group has effective leadership that can influence up and down the foodchain. Effective leadership means a person or persons who have cred in the industry — leader(s) in his/her field.

Adrian Howard said:

Stay with a project from the start to the end. If at all possible be in the same room as the people doing the work on the project at any point – even if this means finding a room and forcing those folk to work there

In my experiences the places where the UX process often falls down is communication. People can very quickly move off track and miss the “whys” behind the design decisions that were made. Without somebody on the spot these can quickly push a project off the rails.

Having somebody on the spot all of the time means you’re available to resolve questions and problems immediately. The inevitable changes due to plan-meeting-reality can be dealt with quickly. You can spend time educating the rest of the team in the UX issues.

(In fact, that last point – educating the team – is the real “most important activity”. The best way to build better products is to stop having a UX Group and start having a UX Company. The best way I know of starting that process is to spend all of your time mentoring people outside the UX Group).

Phillip Shoemaker said:

Prove your effectiveness. Much easier said than done, but let’s make this extremely clear: in many companies, they take user experience for granted and don’t value you as much as they should.

I’ve lived on both sides of the coin: at Palm doing UI after Jeff and company left, and it was taken for granted; people just thought it would happen, even if you didn’t invest in good resources, or user testing, etc. And then again at Real, where we invested significant resources on testing device UIs.

The key is to prove your effectiveness, or show management what will happen to the product/company if they don’t invest in that group/area.

Another key thing to do is to find the real influencers in the company, and get them on your side. Remember that the key influencers in most companies are not the managers. Rather they are particular engineers, product marketeers, QA technicians or the support personnel. Get them on your side, and you’ll start leading by influence, and proving your effectiveness.

Luke Kowalski said:

Automation of the UCD process is the single most important success factor. This becomes more effective the larger the number of applications the designer has to support.
Automation defined:

• Making requirements gathering, prototype review, and quantitative testing a required “bus stop” of the development process (F.e.: Every team must write a user profile before proceeding to the Business Requirement Document)
• Baking in code based templates (UI layout reference library) inside the development tools
• Delivering predefined designs and base widgets as part of a flexible, and modular development environment. Forms and flows can be mashed up and swapped out declaratively, without having to change the code. This design also allows for changes later in the development cycle.

All of the above free up the designer to do front end work like talking to customer and gathering UI requirements, designing the information architecture. It leaves the layout police clean-up work to the tools, and to the development process, the automated part….

Glenn Cochran said:

My answer is simply this…partner, at all cost, with the engineers writing UI code.

The most effective teams I’ve managed always work closely, if not literally side-by-side, with UI engineers. Back at Blue Martini we partnered with engineering and created a shared component library used in mutliple shipping applications. The component library rendered a standard, highly-branded look-and-feel as well as provided desktop-like interactions in a web broswer. This isn’t to say that what we achieved was having all applications so equal they were bland and generic. Each product also had custom code for specific interactions and concepts unique to the product itself.

The impetus for this successful partnering and building of this UI framework was largely driven by the sales team. The suite of existing products with unique visual designs and interaction models was complicating the closure of deals in the pipeline. In addition, the applications could be highly customized during deployment but were not standardized in any way.

The sales team worked closely with my team to refine which applications should be doing what and exactly how they were ultimately demoed, utilized, and deployed. The idea was to simplify the cross product differences while still focusing on the specific roles of users in each product. My team delivered new designs, focusing largely on reusable components, their interactions with the user, and the overall UI architecture (menus, toolbar, navigation, etc.). Ultimately a reusable framework was built by engineering and was used to rebuild four products. The engineers loved the challenge of building the UI framework while the sales team loved the simplified product offering with a standard look-and-feel and extensibility model.

As for the organizational change, the main hurdle was on the product management side. We had to get total buy in from the product managers of each product we planned to convert to this new design. Ultimately we started with two product managers that worked well with my team and proved the concept could work on their two products first. After that, it was only a matter of time before other applications started to look dated and out of sync with the new design and product managers began asking to have their application updated as well.

From concept to implementation, it took about 1.5 years to get four separate products converted and looking/working like one another. The lenght of time was largely related to current release schedules all ready in play. We had to balance new features with the overhaul of the UI design across two releases, typically, for each product to complete the effort.

The end result was a set of applications which worked well, that looked as if they’d come from the same vendor, that were highly branded, that were simpler to use, which provided an improved experience for users that was more desktop-like in nature. The sales team was able to simplfy their demo suite and ultimately sell more product.

For my team, this effort was great deal of work and was often frustrating, but in the end we were highly effective. One thing I learned on this journey was that previous approaches constantly speaking about ROI, ranting about needing to do more user testing, stating how UCD is the most important function in the company, basically were herd but not taken seriously. Once we put on a different hat which focused entirely on the bottom line (closing deals), we were able to get a ton of work done in a reasonable amount of time, that customers and internal folks really loved. They truly appreciated us tackling this challenge and for us we ended up with a reusable framework that helps enforce the design goals we’d set forth.

Andrea Hill said:

Sell the value to the organization as a whole. Provide concrete examples of ROI. Make it known that it is an indispensable part of the process.