Latest Commentary

November 9, 2009

Data Visualization With Circles, Spirals, and Other Round Things

In this post, I’ll be writing about using circles and spirals in data visualization. There are some interesting things you can do when you arrange your data circularly – benefits you don’t get from more traditional layouts. Of course, I’ll also discuss the drawbacks, too. None of these techniques are categorically superior to the alternatives.

This is certainly not an exhaustive review of the topic. There are many kinds of visualizations I won’t be able to explore in a blog post. The common thread here is simply “things I’ve found while researching another project I’m working on for my information visualization class.”

Nightengale’s Coxcomb

One of the earliest examples is Nightengale’s Coxcomb. This graph was created by Florence Nightengale during the Crimean War to advocate for better sanitation. It shows that the number of deaths due to preventable causes (blue wedges) exceeds the number of deaths due to wounds (red) and other causes (gray). It also shows the success of sanitation efforts – the decrease in preventable deaths in April 1855 corresponds to sanitation cleanup efforts in Turkey.

Figure 1: Nightengale’s Coxcomb

The major advantage of the circular layout of the coxcomb is the way months have a consistent placement around the axis. This makes it easier to do year-on-year comparisons. (This will be a recurring theme.)

Nightengale was careful to map data values to the area of wedges, not the radius. This solved one problem, but introduced another. Nightengale was avoiding the problem where area increases as the square of radius. Had she mapped her data values to the radius, this would have exaggerated the values, since a doubling of the radius would show a quadrupling of the area (Rehmeyr, 2009). But by avoiding that lie factor, Nightengale made it somewhat harder to compare months. You can somewhat easily tell that the radius for January 1855 is about twice as long as the radius of November 1854. But what of the area? People aren’t that good at estimating area, especially of odd shapes like wedges (or even rectangles with differing aspect ratios).

Teoria Generale Della Statistica

Figure 2 avoids the area/radius confusion of Nightengale’s coxcomb, by plotting the data as spokes on a wheel. It is also much less visually striking than the coxcomb. It’s okay, sometimes, to sacrifice some utility (but not honesty) to increase impact.

Figure 2: An early circular plot (Gabaglio, 1888)

The graph comes from Teoria Generale Della Statistica, an 1888 statistics book by Antonio Gabaglio. Although the book is cited often by visualization papers, I haven’t found out much about it. And since it’s in Italian, I can’t even tell you what this is a chart of.

One final note about this chart: It doesn’t scale to showing large numbers of years in one plot. You could represent a few years by having several colored lines along each spoke, but you’d quickly run out of colors.

Spirals

By plotting data on a spiral, we can show several years worth of data. Figure 3 shows quantities of a certain food eaten by chimpanzees in the Gombe preserve in Tanzania between 1980 and 1988. Each revolution of the spiral represents a year, and the months are aligned on the spokes. This supports both month-to-month and year-to-year comparisons. And notice that there are no breaks in the data: other, non-spiral, layouts would have breaks, such as between December and January. With the spiral, every data point is adjacent to the the previous and next month, and the previous and next year (Carlis & Konstan, 1998). The downside, compared to a table, is that it becomes more difficult to compare months of the same year that are located on opposite sides of the spiral.

Figure 3: A spiral plot (Carlis & Konstan, 1998)

To compare two or more data sets, Carlis and Konstan placed bars onto the spiral. Figure 4 compares chimpanzee consumption of two food types. The visualization seems fundamentally sound, although it could certainly be improved. At first, I was concerned about perspective effects. Since the spiral is shown in perspective, would the brain perceive bars in the back as larger objects whose sizes have diminished in the distance? The answer seems to be no. I checked, and bars in the front and back that appear to have the same height actually do. (Comparing heights is something the brain is pretty good at.) The display of the graph could certainly be improved to have less occlusion of the blue bars.

Figure 4: Comparing multiple values on a spiral plot (Carlis & Konstan, 1998)

An Aside About Scales and Legends

You probably noticed that there aren’t any labels on the spiral plots I’ve shown. That practice will continue. I don’t have a good explanation as to why that is, but I do have a guess. The visualizations are generally created by interactive programs where the user can specify lots of parameters. I’m assuming the scales and legends (months, years, etc.) are shown in those controls.

However, the nature of the spiral doesn’t leave a lot of room for annotations. The spokes can easily be labeled, but the revolutions of the spiral are harder to annotate, especially if the spiral is tightly wound. Weber et. al. (authors of a paper on the subject, from 2001) suggest making an interactive visualization, where the user gets gets information about the data underneath the mouse pointer.

This is also a good time to mention that Gabaglio, the Italian statistician, did an early spiral chart. I think it’s hard to read (you have to compare sizes of rotated rectangles), but it at least manages to label both axises. You can see this reproduced in The Visual Display of Quantitative Information (Tufte, pg. 72).

Spirals and Periodic Data

The spiral layout can make periodic trends in the data easily apparent, as long as the correct period is chosen. Figure 5 shows the importance of choosing the correct period. The chart on the left has a 27-day cycle (that is, 27 days per revolution), the correct period, 28 days, is shown on the right. There are some data analysis techniques that the computer could use to suggest a time scale to the user (Müller & Schumann, 2008).

Figure 5: The importance of having the correct period for your spiral chart (Müller & Schumann, 2008)

Glass Patterns, Pattern Recognition, and the Kaliedomap

Another interesting feature of circular data layouts is that it can make it easier to recognize patterns. To understand why, we’ll begin by discussing Glass patterns.

If a field of random dots is copied, rotated slightly, and superimposed on the original, people will notice a circular pattern in the dots (Glass, 1969). Simply shifting the dot pattern along one axis (not rotating it) produces a dot field in which it is much harder to notice a pattern (Wilson & Wilkinson, 1998). This leads to the observation that perhaps it will be easier to notice trends in data if they’re arranged circularly instead of rectangularly.

Figure 6: A Glass pattern (Glass, 1969)

Kim Bale tried this in a design she and her colleagues called a kalliedomap (so named because the result resembles a kaleidoscope). Each segment of the kaleidomap plots one value, with time increasing by hours as the angle increases, and time increasing by days as the radius increases (see fig. 7). Bale et. al. compared this with a more traditional cascade plot, where time increases by hours on the x axis and days on the y axis.

Figure 7: Reading a kaleidomap

Figures 8 and 9 show air quality data from London in 2002 and 2004. Traffic calming measures were introduced in 2003, and the graphs are investigating changes that may have resulted. There are some stripes in the data, which are particularly evident in NO as NO2 segment. The stripes are weekends, where there is less traffic and hence less pollution.

Figure 8: “Two Kaleidomaps showing the air quality data from around Westminster during March 2002 (left) and March 2004 (right).” (Bale, 2007)

Figure 9: “Air quality data from around Westminster during March 2002 (top) and March 2004 (bottom) displayed as a series of 2D cascade plots.” (Bale, 2007)

Bale et. al. contend that the striping effects are easier to see in the kaleidomaps than in the cascade plots (and they did some research to support that claim). In my experience, the striping is more striking in the kaleidomap than in the cascade plot. However, the kaleidomap has the drawback that it’s difficult to find the same point in time in different segments – you have to mentally flip a segment upside down to compare it to a segment across the circle.

There’s Much More

There are many more possibilities that I don’t have time to cover here. The papers I’ve cited go into more detail about the solutions they propose. If you’re interested in this subject, they make good reading. And there are many uses of circular visualizations I haven’t covered – clustering and identifying relationships is one such topic.

Evan Dickinson is a former Portlander currently pursuing an MA in interaction design at Simon Fraser University in Vancouver, BC. He blogs about his studies for CHIFOO. Write him at evan_dickinson at sfu dot ca.

References

Bale, Kim et al. “Kaleidomaps: a new technique for the visualization of multivariate time-series data.” Information Visualization 6.2 (2007): 155-167.  

Carlis, John V., and Joseph A. Konstan. “Interactive visualization of serial periodic data.” Proceedings of the 11th annual ACM symposium on User interface software and technology. San Francisco, California, United States: ACM, 1998. 29-38. 3 Nov 2009 .

Gabaglio, A. Teoria generale della statistica. U. Hoepli, 1888.  

Glass, Leon. “Moiré Effect from Random Dots.” Nature 223 (1969). 7 Oct 2009 .  

Glass, L., and R. Pérez. “Perception of random dot interference patterns.” Nature 246.5432 (1973): 360–362.  

Muller, W., and H. Schumann. “Visualization methods for time-dependent data - an overview.” Simulation Conference, 2003. Proceedings of the 2003 Winter. 2003. 737-745 Vol.1.

Tufte, Edward. The Visual Display of Quantitative Information. 2nd ed. Cheshire, Conneticut: Graphics Press, 2002.  

Rehmeyer, Julie. “Florence Nightingale: The Passionate Statistician.” Science News 26 Oct 2008. 8 Nov 2009 .

Weber, M., M. Alexa, and W. Muller. “Visualizing time-series on spirals.” Information Visualization, 2001. INFOVIS 2001. IEEE Symposium on. 2001. 7-13.

 

Posted by .(JavaScript must be enabled to view this email address) at 11:35 am
October 27, 2009

InfoCamp 2009 Notes

A few weeks ago, I went to the InfoCamp 2009 unconference in Seattle. InfoCamp describes itself as “unconference about user experience, information architecture, user-centered design, librarianship, information management & related fields.” For those of you not familiar with an unconference, it’s a kind of conference where sessions are put on by the attendees, instead of pre-screened presenters. I had a great time at InfoCamp, and I recommend attending next year.

These are my notes, from some of the sessions I went to.

  • Death to Static Wireframes
  • Jing Screencasting and Information Literacy Instruction
  • Designers and Business People: Best Friends Forever

Death to Static Wireframes

In this panel discussion, design practitioners discussed the future of wireframes. The panel was:

Matt Turpin: Interaction designer at Ascentium in Bellevue.
Kris Bell: User experience designer
Mark: From Blast Radius. (Sorry, Mark, I didn’t catch your last name or job title.)
Andrew Otwell: User experience architect + interaction designer
Kevin Wick: Designer at Ascentium
Aaron Louie: Associate Director of User Experience, ZAAZ

The panel started by discussing what constitutes a static wireframe. A picture you can’t interact with at all, such as a PDF file, is definitely static. Some panelists considered a basic click-through (static except for clickable links) to be static, too. There’s some gray area.

Each panelist made an opening statement. (And, unfortunately, I didn’t capture Andrew’s statement in my notes.)

Aaron’s Opening Statement

Are static wireframes dead? It depends. They’re not all that problematic for small sites with little interaction. Anything with animation, motion graphics, video, complex interactive controls needs a better representation.

Kevin’s Opening Statement

In his experience, when walking through a static wireframe with a stakeholder, sometimes the stakeholder just doesn’t get the experience will be. Kevin has to do a lot of explaining about what the static pictures mean. The best way of showing the experience is to actually interact with the experience. This gets everybody closer to what the end product will be like.

Mark’s Opening Statement

There’s a danger in letting the tool drive your design solutions. For example, if you’re sketching in Visio, you’re tempted to just use whatever the stencils give you. Maybe that’s appropriate, maybe it’s not. Start with big ideas drawn on paper or a whiteboard. Think of static wireframes as a higher-fidelity sketch.

For usability testing, you get better results from a dynamic wireframe. But your dynamic wireframes don’t need the exact level of interactivity and fidelity as your final project. For example, the wireframe can have less flash and javascript.

Chris’ Opening Statement

Wireframes will continue to exist for executives who want to cruise through a design. Think about who will consume your wireframe. Developers need rich & high fidelity, others don’t need that much.

At this point, I mostly lost track of who said what. Statements are the (unidentified) speaker’s point of view, not necessarily the consensus of the panel.

Question: It’s easy to control a discussion with stakeholders, when using static wireframes. It’s harder to herd cats as the mock-up gets more elaborate. How do you manage the conversation with stakeholders with dynamic wireframes?

That is, interactivity increases fidelity, therefore stakeholders worry about fit and finish.

Expression blend has a module called sketch flow. Things look sketchy. But it is interactive. Expression also has some presentation tools. Aaron was using a beta version, and saw lots of potential. They succeeded in framing the discussion they wanted to have.

Q: What tool do you prefer at the moment?

(Each paragraph is a different panelist’s answer.)

Axure. That panelist has used it solo and with a team. Axure uses subversion for revision control & collaboration. Axure also has the pencil-looking widgets.

HTML + JQuery + CSS. They’re good for low-fidelity prototyping, and they’re the panelist’s final product anyways. JQuery + FireBug + other plugs-ins help for dynamic web sites.

Visio. Pen + paper. Excel (to plug in which content goes where).

Axure. Dreamweaver. HTML + CSS.

Q: Do you prep the clients, before showing them wireframes?

At the start of a client (or stakeholder) meeting, discuss the scope & purpose of wireframe. Remind them that we’re not talking about visual design, copy, creative elements, etc.

80% of the job is managing stakeholder’s expectations. This is more politics than drawing. It helps if you have the same clients over & over again, because then you train them.

Q: Different stakeholders need different documents with different content and different levels of fidelity. How do you automate creating all those documents from one master?

Wow, that’s hard. That’s something of the ultimate goal, but the panel doesn’t think we have the technology to get there yet.

Q: Wireframes are, to some extent, the core deliverable of interaction designers. The other teams (developers, product managers etc.) are used to getting static wireframes. How is switching to interactive wireframes a cultural change in the organization?

Kevin was pleasantly surprised at how well Axure was received. PMs, clients, and developers “get it.”

As for how much time a manager should schedule for creating wireframes, Kevin hasn’t seen an increase in time needed for making the wireframes. The time spent making an interactive wireframe is slightly longer, but the wireframe doesn’t need heavy annotation like a static wireframe does. The time for dynamic wireframes could be about the same, or a little less – Kevin hasn’t done a formal study.

A follow-up question asked how you ensure that developers find all the required behaviors without annotations. You can’t hand them a prototype and expect them to find everything, can you? In response, it was pointed out that Axure has some annotations built in. You can print static, Visio-looking wireframes from Axure.

Comment from QA

A software test person commented that he feels separated from designers by too many levels of bureaucracy. He asked designers to please engage QA earlier in the process. Dynamic wireframes will help QA get a better understanding of how the product is intended to behave. Additionally, the QA person feels like he often doesn’t know rationale behind the design, and this hampers his ability to test.

Q: An audience member tried to use Axure a year ago, and found it limiting for making high-fidelity wireframes

This comes back to not letting tools limit your thinking. Do more sketching outside of a technical tool. Be prepared to murder the ideas you like.

Build your own prototypes (as opposed to having developers make them for you). That gives you more freedom to try 5 ideas and discard 4.

(Note: I don’t think I captured this fully. In my notes, the answer seems disconnected from the question. That wasn’t the case in the presentation.)

Q: Is there a clear distinction between when wireframe is done & when you start the site?

This is a common situation: The wireframes are locked down. Then you get to copyrighting, and copy writers argue about the space needed for text. Then more changes happen. The wireframe isn’t as locked down anymore.

An agile design model could help here (analogous to agile development). Keeping UX involved longer in the process could also help, to remind people why page elements are there.

It helps to work with copy writers during design. Use high-fidelity wireframes for this. You should also design contingently: What if I get 20 words of copy here? What if I get 200? Know that your copy will change over time. Your design will outlast the initial copy.

Content is not just words – content is everything & anything (videos, etc.).

Jing Screencasting and Information Literacy Instruction

Jing is a tool for making quick and simple screencasts. The presenters, librarians at the University of Washington, discussed how they use Jing to support their patrons.

Screencasts are video recordings of an application’s window, demonstrating how to use an application. The librarians started using Jing because it easily lets them do video tutorials – for example, how to search using the library’s web site. Because Jing is a light-weight tool, there’s little cost to re-doing the tutorials after a site change. Also, many of the ideal librarians to create the tutorials have limited technology skills; they don’t want to learn a complicated video-editing package.

The librarians found Jing so easy to use, they started using it for one-off support situations. When supporting a patron via online chat, it’s easier to record a quick screencast showing the patron what to do than to describe it textually.

The presenters put their notes up on the web, so I’ll link to them rather than repeating the information here: http://docs.google.com/View?id=dd8gk9tj_18s84x2mf6

Designers and Business People: Best Friends Forever

This was my session. Sometimes marketing and management can be a valuable ally for designers. Sometimes they’re an obstacle to overcome. I led a group discussion about why that is, and how to improve relations between designers and business people.

Most of the questions and advice came from the group. This was great for getting breadth of perspectives. However, like the wireframes panel, I don’t have names to go with the comments. I’ve generally put one speaker per paragraph, but not always. If a paragraph has contradictory viewpoints, it’s probably the opinions of two different speakers.

Video of the talk is at http://www.ustream.tv/recorded/2336539

Question: Who are business people?

That is, who are the people we’re talking about how to get along with. Marketers and project managers are very different people.

One agency worker’s perspective: Who you work with varies. In some accounts, work with the CMO & COO. Other accounts: work with people who are more of a product manager type role. Try not to work with only the product manager. The product manager answers to a room of other stakeholders. The other stakeholders probably need to be involved, but it can be unclear who to get.

Another agency worker offered this advice: Have managers of your group & managers of the other group get together for a conversation of what’s guiding decisions. When you deal with someone, you deal with their whole org chart. The more you can find out about the pressures on them, you’ll be able to help them, and they’ll feel that you’re helping them.

Frame your pitch in terms of what your business partner cares about. In my job, worked with product planners who were concerned about creating a launch message. When I’d talk to them about design and usability issues in terms of how it affects the launch message – talk to them in their language – I got better results.

We’re all service workers – internal or external. Think of providing customer service to your clients & business partners. Understand what someone needs, and appeal to their sense of importance. Business folks, we think, learn this in business school; designers don’t formally learn this.

Stakeholder management would be a great college class. Some UW students and graduates report that their MSIM (masters in information management) program covers this (not in a class that’s actually called stakeholder management – they picked it up over several classes). They learned how to pull out concerns from their stakeholders: . Asking why stakeholders asked for features, to get at stakeholders’ rationale.

In an agency, it’s important to have a strategy of how you’ll deal with clients. Especially troublesome or difficult clients. Know some of the red flags, have an agreement of how you’ll go through it.

Q: How to deal with last-minute changes?

One participant has a challenge where some influential business stakeholders will not engage with the rest of the stakeholders or the design team. They wait until the last possible moment – everything has been signed off, nothing is supposed to change, a few days until site launch – then they muster all the power they have to completely change everything. No time left for anyone to provide feedback or pushback or discussion.

One suggestion: Put everything in writing. The contract can say “we have 4 design iterations, anything over that, you’ll pay more money.” But being legalistic about the contract isn’t always the best approach. Come from a customer service approach, and negotiate how to meet in the middle. This helps maintain a relationship – you need this for internal or external clients. Make it clear what the effect of the changes will be; give a clear timeline. If you do this right, your stakeholders will be happy that they’re listened to. One participant gave an example where he buttered up the client, starting the conversation with how the client’s ideas would improve the project, and then moved on to discussing the ramifications of the change. This changed the client’s tone, because designers validated her.

The participant with the stakeholders who delay clarified his problem: He thinks his stakeholders are trying to avoid design by committee. They don’t want their message and goals to be distorted or watered down, or to have to go to 24 meetings to advocate for what the stakeholder wants for the site. The lesson learned is to have the stakeholder who did the delay tactic engaged early. Don’t let him skip meetings. Appeal to his sense of importance to engage him.

Q: Business people in peer relationships

The questioner deals with stakeholders every six weeks or so, but has business peers he deals with every day. How to help those day to day relationships?

Acknowledge that good ideas can come from anywhere. Don’t rule out ideas from the rest of your team, just because they didn’t come from the designer.

There’s the stereotype of the opinionated designer. When the designer’s work is criticized, it can come across like a personal criticism. Designers need to foster an environment where they can be criticized effectively.

Q: How to extract knowledge from product planners?

When working with product planners, the questioner needs to find out what a product is going to do. It’s hard for her to get the product planners to reveal this information. How to get that information from the product planner, and hold the planner accountable?

Building a personal rapport with the product planner makes the rest of the process easier.

A planner will often say something like “What we want it to do is be successful.” The value you bring as a designer is to bring concrete representations. Sketch, with many iterations. Ask “Is it this? How about this? This?”

What’s missing is for people to understand the role of design in the business. If you can base your recommendations on data, not opinion, you get more respected. Talk about design decisions from a business point of view.  Also, program managers think in terms of features. The designer’s job is to make those features work together.

The product manager is probably doing some early research to define the product. It would be great if the designer was invited, but often times you’re not. Even if you don’t come along, you can ask lots of questions about the research. Examine the findings. Ask deep questions.

“As designers, our jobs are so cool that everyone wants to do them for us.” So give people paper & pencils, and let stakeholders do some design work. (Especially early in the process.) If you have some pre-seeded ideas, you can direct the conversation a little bit.

Another needs analysis tactic: Come with some post-its, and have everyone write down the most ideal thing that could come out of this project. Put them on the wall, affinitize them, and discuss.

Ask what the value of the design is. By what criteria will the design be considered successful? Use that as a starting point to derive what the product planner wants.

Stakeholders will propose a solution. You need to understand the problem they’re trying to solve with the solution. Propose alternatives.

Q: Evangelism

What approaches do people take for evangelism? How do you educate clients and managers.

For usability testing, let stakeholders watch. Or have video clips / highlight reels. Let stakeholders see the “aha” moments.

Let a third party do the evangelizing. Give them something to read (e.g, The Inmates are Running the Asylum). Or maybe just photocopy a chapter, if they’re reluctant to read a whole book. Sometimes, your point is in the title or summary of an article – even if they don’t read it, they get some of the message. A third party gives the message more credibility than just you.

If you know what brands your stakeholders respect, you can talk about what that brand does. But make sure you’re accurate – they’ll know what their competitors do.

For external clients, let your sales team educate clients on your process. It’s challenging to take an approach to a project that the sales person hasn’t sold to the client.  Sales is where the approach with the client is defined. Then by the time you do the work, you’re contractually locked in to do the approach you want.

For internal clients, try to get involved early in the planning process. “We can make your planning documents look way cooler. We can get in screen shots. Would that be helpful?” Tell the planners: “If you want this 6 months from now, here’s a process we can use to get here.”

Speaking of sales, it helped to have the designer go on a pitch. It’s a good time to educate the designers about what stakeholders are concerned about. There’s also a time to be the guy in the black turtleneck, as a sales technique. Especially now, since the concept of design thinking is big & hot in the business community.

Q: Design thinking and business strategy

Where do design thinking and business strategy intersect? Where can designers help, and where do we have no business giving advice? Sometimes we can do our jobs so well that business people listen to our design suggestions and start listening to our business suggestions.

Identifying an unmet need, and bringing it to the attention of management, is a legitimate role of designers. But that’s different than saying “put all your eggs in this basket,” and advising how the business allocates its funds – that’s dangerous.

Follow-up: What is design thinking? What does the buzzword mean?

Design thinking is taking a design process and applying it beyond designing an object/web site. A natural extension of contextual design – understand how an object fits in its context of use. IDEO started going into the medial field, and found that the problems that need solving are larger than just the devices – the design process uncovered systemic problems. Apply design methodologies to business problems: Sketching, prototyping, systemic thinking. Use these to improve a business. This is related to service design – how do we improve a business process?

Because it’s a buzzword, business people, and even engineers, are more receptive to talking to designers. You can use this to your advantage.

Evan Dickinson is a former Portlander currently pursuing an MA in interaction design at Simon Fraser University in Vancouver, BC. He blogs about his studies for CHIFOO. Write him at evan_dickinson at sfu dot ca.

 

Posted by .(JavaScript must be enabled to view this email address) at 2:04 pm
October 9, 2009

Interaction Design at Simon Fraser University

This is the first in a series of posts I’ll be writing for CHIFOO. I’m Evan Dickinson, a Portlander and CHIFOO member who recently moved to Vancouver BC to study interaction design at Simon Fraser University (SFU) in the School of Interactive Arts and Technology (SIAT). Before I left Portland, David Stubbs asked if I’d be willing to write about my time at SFU.

In this post, I’m going to to talk about the SIAT program at SFU – what’s in the program, why I chose it, and where I hope it will take me.

The biggest draw of SIAT for me is the interdisciplinary program. Many universities with programs addressing interaction design approach IxD by expanding on an existing discipline: Growing a design program or information school to include interactive technology. SIAT feels more inclusive – there is a home for people from various disciplines, and the program doesn’t feel like it’s geared towards just one discipline.

There are many fields of research at SIAT, and I’m still learning about them all. They fall into the general categories of knowledge computation, social and human experience, media and culture, scientific methods, and media art. My interests fall mostly in the social and human experience area: Interaction design, design ethnography, computer-supported cooperative work. And knowledge computation has some interesting aspects, such as visual analytics and visualization.

SIAT is a research-based program. (From what I hear, Canadian grad schools tend to place more emphasis on research than American grad schools.) The idea is that I’ll take coursework during my first year, then spend the bulk of my time in my second year doing a research project. I like the emphasis on putting my skills to use, and actually making something.

So that’s the long-term plan & possibilities, but what am I doing right now? I’m in two classes, information visualization and new media. I’m also the teaching assistant for an undergrad senior design studio, where the students apply their skills on a year-long project.

In the information visualization class, we are starting out by exploring human perception and using that as a foundation to explain why some visualizations do and don’t work. For example, when learning about color perception, we learned that people tend not to be able to separate the dimensions of color. It is difficult to splice a color apart and perceive red separately from green and blue. It is somewhat less difficult to separate hue, lightness, and saturation, but still not optimal. The graphic below indicates population density with hue, and change in population with saturation and lightness. You can sort it out, with some effort. The textbook author recommends using color for one variable and another attribute, such as texture or shading, for the other variable. (Ware, 135-137.)

(Map: U.S. Census Bureau.)

The new media class is about analyzing the design principles that go into new media works; things like narrative, representation of space and time, analyzing strengths and weaknesses of a particular medium, and the ways in which a work is immersive. This is is the most culture-centric class I’ll take – designed to give me some breadth. It’s been a healthy change for me. I’m used to analyzing designs only in terms of how well they support the user’s effectiveness in the workplace, and now I’m learning to use criteria that are less narrowly focused.

I’m the teaching assistant for a capstone project for the undergrads in SIAT. The students form interdisciplinary teams and work on a project of their choosing. They go through the whole project life cycle: inquiry, design, development, testing, and launching. Right now, their projects are still in the early stages. Even so, they are already planning cool things. We have teams who want to build rich media experiences, tangible devices, games, projects to encourage sustainability, and much more. I’m excited to see what the students come up with as the year goes on.

So that’s how my graduate program is starting out. I’ll have more to say as my education continues. I welcome questions – the point of these articles is to share what’s interesting, and your questions will guide what I write about.

References

Brewer, Cynthia A., and Trudy A. Suchan, U.S. Census Bureau, Census Special Reports, Series CENSR/01-1, Mapping Census 2000: The Geography of U.S. Diversity, U.S. Government Printing Office, Washington, DC, 2001.

Ware, Colin. Information Visualization: Perception for Design. San Francisco: Morgan Kauffman, 2004.  

Posted by .(JavaScript must be enabled to view this email address) at 9:52 am
August 6, 2009

Architecture and User Experience (Part 10: Pieces of the Puzzle)

Finally, after 10 months of wide ranging discussion, I’ll touch on the parts and pieces of a User Experience Architecture.  In addition to describing the Puzzle Piece Meta-model as a framework, I will go into detail about each of the pieces themselves.

The puzzle comprises four main areas:

  • Quality Attributes - the branding experience - the emotive qualities of the experience - the impact of the experience
  • Models and Use Patterns - the user behaviors, work models, contexts, mental models and patterns of use the experience must address
  • Design Language - style guides, visual representations, interaction standards, widget libraries, content architectures - how the experience is represented to the user
  • Design Principles - the underlying, fundamental principles to guide decisions about the experience - perhaps the one thing to distinguish this “architecture” from any other

The Puzzle Piece Meta-model

Hugh Dubberly’s May/June Interaction’s article provides a great survey of models and frameworks - a sort of meta-model of meta-models. It’s wonderful and I highly recommend it. (ACM Digital Library subscribers can see the full article online - here is the bibliographic reference with links to the online version for subscribers). I’ve spent most of my design career self-consciously considering the model I use even as I design the object itself. Our tools craft our models; our models craft our perceptions, and hence our designs are affected by the modeling frameworks we employ.

I prefer cyclical diagrams - I am a strong believer in spiral progression: we continue to revisit the same problems and situations, but never the same way twice. Linear models are too definite - most real world experiences are a continuum with no definite starts and stops. Even birth and death are stages in a continuum, depending on your point of view.

The Puzzle Piece Meta-model is a closed cyclical diagram with five parts. The outer four “puzzle pieces” interlock, each invading the territory of its neighbor. If I were more clever, I would have found a way of representing the pieces so that all four interlock with each other - perhaps as a star pattern, or maybe a 3D globe - because in fact, all parts of the framework touch all other parts. A decision made in one area depends on and affects decisions made in the other three areas.  The fifth part - the center - is the experience itself. It comprises the objects, artifacts, built environments, phone scripts and any other user facing elements actually delivering the experience. It is intentionally left blank as the experience morphs considerably over time and from project to project.

The puzzle pieces do not morph considerably over time. They change when the user population changes, the technology infrastructure changes, or the business model shifts. None of those move rapidly or dramatically compared to the myriad possible experiences an organization could deliver.

The diagram has several faults in addition to the aforementioned lack of total integration of all four pieces. It is too “slick” - its clean edges and corners suggest a finality and completeness that I’m quite certain is hubris. It’s not nearly architectonic enough for my aesthetic - it’s crude. But it’s sufficient to communicate to business and engineering stakeholders without my having to explain the meaning of each piece (even if I do have to explain the content of each piece).

Contrast my Puzzle Piece Meta-model with Morville and Callendar’s Treasure Map of User Experience Deliverables. Although their stated goal was not to develop a meta-model for user experience design, many of their deliverables map well into my puzzle-piece meta-model. As I describe each piece I’ll also reference example deliverables from the Treasure Map.
 

Quality Attributes

I don’t know from where I lifted the term, but I like it. It is used in lots of contexts. I like its multiple ambiguous meanings.

Quality - as in “peculiar and essential” characteristics, not as in “degree of excellence.” I use it to emphasize the non-quantitative aspects of the experience. So much of our training and guidance in user experience stems from gathering data. I included this adjective to reinforce the importance of emotive aspects of the experience.

Attributes - a way of purposely blurring the edges of the experience - the experience isn’t a set of things, rather it is a set of attributes that surround the thing. The phenomenological debate surrounding experience design (can we really design experiences, or design for experiences, or design contexts in which people have experiences, etc.) is not terribly interesting to me. I leave those distinctions to the philosophers. I do know designers and architects have been intentionally creating opportunities for others to enjoy and experience their creations for millennia. It is this self-conscious intentional act of creation I’m referring to with respect to designing experiences.  This quadrant of the meta-model describes attributes of the experience I hope people will discover, encounter and desire.

Put together, these two words describe the aspects of the experience that are emotive, non-quantifiable and create a long-lasting impression. The Quality Attribute piece of the puzzle covers key characteristics of the experience users expect, demand or desire.

To illustrate my point, consider two completely different design problems: a game and a rodent trap. For the game we are likely interested in creating an immersive experience with lots of “flow.” We’ll likely want to seduce the user and tease them as a way of enhancing their engagement. For the rodent trap, we will likely avoid seduction (for the human user, perhaps seduction of a different kind for the rodent), enhancing safety and security (again for the human, but also possibly for the rodent) and depending on the design, the humaneness of the device. In the first design problem we may wish to create an engaging experience for children; in the second we’d likely want to push children away.

Quality Attributes deliver the brand promise - the two are reflections of the other.

Nothing in the Treasure Map deliverables directly correspond to this aspect of the Meta-model although a few of Morville/Callendar’s deliverables include these qualitative aspects.

Models/Patterns

Most user research, usability and user-centered design activities and deliverables are part of this puzzle piece. Mental models, work models, contextual inquiries, most of the pre-design deliverables discussed in my last article all fall under this puzzle piece. This piece is where we determine and describe the users’ context, behaviors, work breakdowns and other artifacts to which our designed experience must respond.

Some would claim the models and patterns are the UX Architecture, but as I argued in my last article, while a crucial pillar in the structure they are not sufficient to comprise an architecture. If only the contents of this puzzle piece were the architecture, then Software Architecture would be an appropriate framework for a UX Architecture (since Software Architecture comprises many of the same kinds of deliverables contained in this section). But as the most recent article pointed out, Software Architecture is not a sufficient framework to support a UX Architecture.

Note how Quality Attributes integrate with Models / Patterns: if we believe a key Quality Attribute of our designed experience is to attract the user, we must have data, contextual models or other formalisms to support that position. The obverse is also true: an observation of our users’ habits must inform us as to what is attractive to our user base and hence inform our design direction accordingly.

Almost all of the Treasure Map components correspond to this portion of the Meta-model, including: Stories, Proverbs, Personas, Scenarios, Analytics, User Surveys, Concept Maps, System Maps, Process Flows, Story Boards, Wireframes and Narrative Reports.

Design Language

The Design Language we choose is crucial to expressing the experience itself. Our choice of colors and geometries, even our use of language itself are the direct interfaces people have with our designs. Whether we are designing an artifact, and environment or a new service, there is always a “surface” with which our users interact. This piece of the puzzle addresses the thousands of micro-design decisions necessary to communicate the Quality Attributes and embrace the discovered use patterns.

Typically an Architecture has a “style guide”, specifications, standardized controls and prototypes that define the boundaries of the solution space so that multiple designs over time reflect a coherence with an underlying structure. This puzzle piece covers all of the vocabularies (visual, interactive, architectural, content) we will use in our design.

Consider the rodent trap example. The aesthetic choices for the trap itself, the material, its packaging and the supporting marketing communication are all specified in this puzzle piece in support of the use models and Quality Attributes defined in the other pieces.

Most of the remaining deliverables in the Treasure Map fall into this area: in addition to Design Patterns, Style Guides and Specifications, I would include Concept Designs and Prototypes.

Design Principles

A design is part of an Architecture by virtue of its conformance with the underlying (or overarching) design principles laid out in the Architecture. Through a self-conscious, intentional choice of principles, the architect establishes a framework tying the other pieces together.

Design Principles are perhaps the most important ingredient to an Architecture; without them we would still have a design, or an engineering solution, but we wouldn’t know whether our design was part of a larger constellation of designs belonging to a common architecture.

According to Bill Buxton, one process distinguishing design from engineering is the formal nature of “critique.” Architects critique another’s work by reflecting on the Design Principles inherent in the solution. Either the work is criticized because of the (poor or inappropriate) choice of principles, or it is critiqued because it fails to conform to the explicitly chosen principles. In any event, designs can only be evaluated in the context of their Design Principles.

There are literally hundreds, if not thousands, of design principles. It is up to the Architect to decide which principles are key and which can be ignored. The choice of principles depends on several factors perhaps most critically, the subjective aesthetic of the Architect. When you decide to hire an architect, choose carefully - her design “aesthetic” (which principles she holds dear) may conflict with yours.

In the Puzzle Piece framework, Design Principles must be consistent with the Design Language, Use Patterns and the Quality Attributes. That is, the Design Principles must inform these other puzzle pieces as well as be informed by them.

A few articles back I made passing reference to three Vitruvian principles: firmitatis utilitatis venustatis, translated roughly as strength, utility, and beauty in the context of “elegant” design. Vitruvius, a Roman Architect, engineer authored his famous “10 Books of Architecture” over 2000 years ago, and briefly mentions these three characteristics as inherent to any design. I put these design characteristics together into a single “Vitruvian Principle.” For me, the Vitruvian Principle is a key metric I use to evaluate a design proposal: Is it robust? Is it useful? Is it appealing?

Which principles the Architect chooses and their relevance to the targeted audience is one meta-decision to be made. A second is how many principles to abide by.

Mies van de Rohe, a mid-20th century pillar of German and American Modernism, is famous for his design principle “Less is More.” The absurd conclusion of this principle leads to it being the only principle. Minimalist designs, Google’s home page for example, are driven by this principle.

Sticking to a single design principle (assuming for the moment it’s even possible) drives a purity in the solution. Assuming the design team is successful in driving an expression of this principles, users will feel its impact.

A single principle for most non-trivial design problems is likely impossible. At best it leads to tedious results, at worst, broken. If one principle is not enough, what is the upper limit? Theoretically there is no upper limit - one of the joys of Architecture is juggling the number of design principles. For some Architects, dozens of principles come into play as justifications for specific design decisions. It comes down to an individual’s capacity for keeping multiple balls in the air.

I top out at about a dozen principles for the most complex problem spaces; beyond 12 my design solutions become diluted by too many competing influences. For less complex problems, a handful of principles is usually more than sufficient. But again, this is a subjective decision, completely integrated with the Architect’s aesthetic and competency.

Finally, to be an Architecture, the Design Principles must be chosen intentionally and before the design is complete. Some may be picked a priori because they are part of the Architect’s aesthetic; others may be brought into play as new information about the problem is revealed. But as a new principle is brought into the Architecture, all of the prior decisions must be reviewed in light of the newcomer. The coherence of an Architecture depends on the interplay between the meta-decisions (Design Principles) and all of the design decisions. We don’t get to pick and choose which principle applies to which aspect of the design and still call the solution an Architecture.

This last piece of the puzzle is extraordinarily self-conscious. It is the constant reflective activity of design, in this case not on the experience design, but rather on the design of the Architecture itself.

So that’s about it. I’ll finish up next month with some reflections on how to get started in crafting an architecture and how you know you’re done.

Posted by leofrish at 8:00 am
August 4, 2009

Architecture and User Experience (Table of Contents)

A set of links into the complete series of articles.

Architecture and User Experience (Part 1: The Politics of Architecture)
Architecture is fundamentally about politics. Whether the architect is fighting for the rights of neighbors to maintain their neighborhood’s character, or acting on behalf of those in power, the architect’s work has significant impact on the lives of thousands of people.

Architecture and User Experience (Part 2: Architecture As Strategy)
Architects generally have a “seat at the table” simply because seating them anywhere else has proven unacceptably costly to owners. Economics make the Architect a strategic player.

Architecture and User Experience (Part 3: A Sustainable Process of Design)
If we are complicit with those in authority who pay lip service to user experience, but fail to invest in it, we fail in our responsibilities to the people who matter most to the business, the customers. We not only fail to do our job, we fail to engage in an essential political process: shifting the business to pay attention to its users.

Architecture and User Experience (Part 4: Architecture and Activism)
How do we shed light on the value of user experience as a strategic part of the business?  How do we get management to open up before the business is in crisis and it’s too late?

Architecture and User Experience (Part 5: An Agile Process)
Until business incorporates user experience as a component of strategy (as it will eventually) we must work hard to craft good luck. Guerrilla techniques, often agile in nature, can go a long way to institutionalize change.

Architecture and User Experience (Part 6: An Ecology of Use)
User Experience Architecture is a process of identifying, describing and ultimately designing the ecology of use for a product or service.

Architecture and User Experience (Part 7a: Getting to Know the Problem)
Designing solutions to real problems means getting to know the problems. Understanding our users’ problems isn’t a luxury, a distraction or an unnecessary expense - it’s half the solution.

Architecture and User Experience (Part 7b: Getting to Know the Problem)
Recognizing the fundamental need for research is crucial to building world-class products. Choosing the right research approach for the problem is equally important.

Architecture and User Experience (Part 8: A Form of Software Architecture?)
How do we communicate our findings in ways our stakeholders will understand? If we’re working in a software engineering environment, might the diagrams and deliverables used by software engineers give us some clues?

Architecture and User Experience (Part 9: The Puzzle Piece Meta-model)
If software architectural models are insufficient to represent User Experience Architecture, what other disciplines might guide us in communicating with our stakeholders?

Architecture and User Experience (Part 10: Pieces of the Puzzle)
Our tools craft our models; our models craft our perceptions; our designs are affected by our modeling frameworks. The Puzzle Piece model describes the four interlocking constraints/pillars supporting and circumscribing the design of the user experience.

Posted by leofrish at 3:53 pm
July 9, 2009

Architecture and User Experience (Part 9: The Puzzle Piece Meta-model)

In the previous article, I had hoped to define User Experience Architecture in terms of Software Architecture. The idea was our engineering teams might be able to better understand us if our deliverables were defined in terms they recognize.

I’ve concluded the approach is fatally flawed for several reasons:

  • Software Architecture is an engineering discipline;User Experience Architecture is a design discipline
  • Software Architecture deliverables (UML diagrams and the like) have no analog in the User Experience domain
  • User Experience Architecture begins with fundamental research into a target user population; Software Architecture has no equivalent dependency
  • Software Architecture’s notions of interfaces, classes and patterns have weak or no equivalents in User Experience Architecture

Perhaps a better starting point is from the field of bricks-and-mortar Architecture.

In Architecture, practitioners are expected to develop several deliverables prior to creating a design:

  • Urban context study
  • Project pro-forma
  • Transportation study
  • Relevant code analysis
  • Site study
  • Program analysis
  • Life-cycle cost analysis
  • Affinity Matrix
  • Space / FAR analysis
  • Bubble diagram

All of these methods of mapping the contexts of the proposed building (environmental, legal, operational and behavioral) require time spent researching. They involve multiple visits to the proposed site, meetings with city officials, research into buildings of a similar “type,” discussions with engineering specialists and possibly meeting with neighbors and future occupants.

Are there equivalent deliverables in UX Architecture?

“Deep dives” into a target user community to witness work and play in situ such as I discussed in a previous article are similar to the Architecture research phase described above. A non-exhaustive list of deliverables resulting from a modest qualitative research project could include:

  • Persona definitions
  • Work flow modeling
  • Artifact analysis
  • Social network analysis
  • Affinity diagrams
  • Power / Status relationships diagrams
  • Collaboration dependencies
  • Scenarios
  • Quality attribute identification
  • Use Patterns
  • Relevant Design Principles

This list and the one for Architecture pre-design efforts both describe externalities to a design.

Does that mean a User Experience Architecture is merely the identification of key externalities resulting from an intensive research process?

No.

User Experience Architecture is more than a summary of the research results, just as bricks-and-mortar Architecture is more than sum of its pre-design research. Although pre-design research is not the architecture, it is one of the key deliverables on which stakeholders base their “go/no-go” decision.  Interestingly, stakeholders in the bricks-and-mortar domain do understand the relevance of the pre-design data. Not so for the UX Architecture stakeholders. No matter how obvious these data might be to fellow designers, they fail to communicate a compelling vision to business stakeholders who hold the purse strings and development stakeholders responsible for building the experience. One of the biggest challenges facing UX Architecture is how to deliver research results in ways stakeholders can understand and use.

Communicating a Vision to Business Stakeholders

Continuing the comparison to Architecture reveals other interesting distinctions. Many Architectural firms specialize in the pre-design services and deliverables I listed above. Often an owner will contract for these services to create a pro-forma business case for getting a loan or for identifying the ROI among other reasons.  While a pretty picture of a proposed building might help make the pre-design information concrete, in many cases this level of visualization is unnecessary: the numbers, constraints and recommendations based on the pre-design research are sufficient to identify whether the project is feasible: that it makes sense from a business perspective.

For several years, Usability Engineering has provided similar “pre-design” research services expecting business leaders to make similar pro-forma decisions on the feasibility of a project. Oddly, few businesses I’ve been a part of have been able to visualize the business potential based solely on user research results. Even a “pretty picture” won’t tip the scales in favor of moving forward with a proposed experience. Why can the bricks-and-mortar business managers see the potential where their software business equivalents can’t? 

Perhaps Architecture has succeeded because:

  • Architecture (and its myriad examples of specific buildings) has been around for thousands of years (so owners have inherent understanding of what a building is)
  • Building owners are better versed in the language of architecture than their software business counterparts
  • Architects provide business-relevant data in their pre-design deliverables, including: risk assessments, financial impacts, budgets, construction approaches consistent with a budget.

    Or, perhaps UX Architecture has yet to succeed because:

    • No amount of research will compensate for UX Architecture’s lack of standing in the business models of most companies
    • Business owners have few examples of excellent UX Architectures to learn from
    • User research data as provided by the User Experience discipline has been insufficient or inappropriate for business leaders’ needs.

    Communicating a Vision to Engineering Stakeholders

    On the engineering side of the equation, communicating a vision based solely on our research is equally problematic. Can Architecture provide an analogous model?

    If we imagine software engineering teams are similar to the systems engineering teams in a large scale architectural project (structural, HVAC, soils, electrical engineers, and so on), we can evaluate the relevance of the pre-design documents to the relative disciplines. Architectural engineering teams are very familiar with pre-design research deliverables. These supporting consultants take advantage of the data to help determine their initial scope of effort, risks, systems choices and more. Many times they will participate in the research activities as well since their expertise is often required. How many software engineers participate in UX pre-design research activities?

    But maybe software engineering teams are not like the supporting engineering teams in Architecture. Perhaps we should consider software engineering teams as the contractor in an architectural project (responsible for implementing the building). Here again the two disciplines have very different relationships to the pre-design research.  Where bricks-and-mortar contractors can quickly see how a particular site, building type, and other pre-design information will impact the cost and complexity of a project, software teams cannot envision the end-game based only on the user research results. In some building contracts, the contractor is hired to assist the Architect in doing the pre-design research. Again, how many software engineers participate at this stage of design?

    Regardless, merely providing the results of our research without providing concrete examples of how that research points to the future is an insufficient set of deliverables to communicate a vision; research results alone do not constitute a User Experience Architecture.

    Why User Experience Architecture isn’t Software Architecture

    If I haven’t hammered the point home enough, here’s a final nail in the coffin regarding Software Architecture as a model for User Experience Architecture. How many business stakeholders care about Software Architecture? How many business stakeholders use Software Architecture diagrams to support their business objectives? To what extent do Software Architects provide their analysis and design to individuals outside the discipline? To what extent does Software Architecture make or break a business model? Do Software and User Experience Architectures share a similar relationship to the business?

    Put in this context, the only thing these two disciplines share is the title.

    I am not suggesting the two disciplines aren’t intertwined. It is obvious to us (in the UX Architecture domain) Software Architecture is a subset of the user experience. Just as the engineering deliverables on bricks-and-mortar projects are folded into the overall architectural statement of the building, so too, engineering deliverables must be folded into the overall architectural statement of a company’s offerings.

    Similarly, as Architects have learned to communicate key information to building owners, so too UX Architecture is obliged to communicate to business stakeholders in ways they can understand and take action.

    A View Model for User Experience Architecture

    What are the parts and pieces of a User Experience Architecture?

    Recently, Peter Morville posted an article (with Jeffery Callender) attempting to highlight a list of User Experience Deliverables. The list is wonderful, including many of the items I describe above, along with several design deliverables distinct from research and analysis deliverables. Can we simply provide this inventory of deliverables as the description of a User Experience Architecture?

    No.

    The list of deliverables are constituents of a User Experience Architecture, but they do not provide a view model for the architecture. As Morville and Callender suggest at the end of their article, the vast number of deliverables constitute the proverbial trees blocking the forest. They create a “treasure map” as a description of the many different ways designers may reflect the experience, but they don’t provide an integrated model of an “architecture.”

    Just as Software Architecture is viewed through the lens of a Model or Framework, so too I view User Experience Architecture in the context of a meta-model. I propose the “Puzzle Piece” framework:

    In this Architectural model, the user experience is framed by four major categories of activities or deliverables: Design Principles, Quality Attributes, Models/Patterns and Design Language.

    In the next article, I’ll describe these pieces of the puzzle in greater detail. As a test of the framework, I’ll map each puzzle piece to the deliverables commonly provided by user experience designers, including those proposed by the Morville/Callender inventory.

Posted by leofrish at 8:00 am
June 4, 2009

Architecture and User Experience (Part 8: A Form of Software Architecture?)

I’ve spent several months making wild claims about the importance and strategic value of User Experience Architecture, especially for businesses seeking opportunities in new ecologies of use. But how do we communicate these architectures? What are the deliverables we provide to our stakeholders, clients and users that describe the parts and pieces of a User Experience Architecture?

In the last article I revealed how our internal stakeholders, often not trained in the art of design, will likely find our design-focused deliverables incomprehensible and unactionable. For User Experience Architecture to fulfill its promise, it must communicate the vision of the new ecology of use in ways stakeholders will understand. As with many compelling and persuasive proposals, the results of research may best be leveraged when they are transparent: integrating our research into the vision may be more persuasive than breaking it out as a separate deliverable.

I was talking with Brian Jamison, Founder / CEO of OpenSourcery a Portland-based custom software development shop the other day about User Experience Architecture when I had a flash. Software Architecture is a relatively easy concept to describe (even if designing a Software Architecture is anything but easy). Can we take a page from Software Architecture’s book and use it as a means of describing UX Architecture?

From Wikipedia:

The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them. The term also refers to documentation of a system’s software architecture. Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects.

That’s good. It has a lot of great terms like “system”, and “structure” and “components.” It talks to ideas of “high-level design” and documentation and especially the last sentence allowing “reuse” and “patterns.”

In the context of software engineering (or any system engineering domain, really), these are the underlying meanings of architecture: a kind of high level blueprint of system components that reveal design intent; a kind of “master plan” allowing individual developers to have a sense of what to do with their specific local piece of code.

In the world of bricks-and-mortar Architecture, this would be roughly equivalent to the master plan for a large campus or urban area.

For software engineering, the deliverables that describe the architecture are varied and are based on the notion of “views.” Indeed, the Wikipedia article suggests views “are analogous to the different types of blueprints made in building architecture.”  These include Functional/logic view, Code/module view, Development/structural view, Concurrency/process/thread view, Physical/deployment view, User action/feedback view, and Data view.  In fact none of these views look remotely like the things building architects produce, unless you are willing to stretch your definitions. I suppose we could imagine “Functional/Logic View” to mean “bubble diagram” (the arrangement of spaces in accordance to desired use), and “Development/Structural View” to mean “Structural Engineering Documents” (in which the structural members of the building are called out with associated structural equations), but beyond that there is virtually no relationship to building architecture deliverables.

What would the analogous components be in a UX Architecture? As I chatted with Brian, I thought about some of these architectural “views.” Any discussion of Software Architecture rapidly focuses on meta-constructs: frameworks, models and other means of framing the architecture rather than a direct description of the architectural components themselves.

 

     

For example, the figure describes the Reference Model of Open Distributed Processing (RM-ODP). It is a “view model” providing five different viewpoints into the system and its environment. (I think it’s a little ironic the center image is of high-rises, apparently meant to represent the architecture itself):
     

     

Image of RM-ODP Model
     

 

 

     

A better visualization of the deliverables of Software Architecture might be the diagrams used to describe each of those views. In this case a “collage” of UML diagrams:
     

     

UML Diagrams 
     

 

This is more like it! Lots of imagery and schematics and blueprint-like artifacts!

What would the equivalent diagrams be for a UX Architecture?

Here’s where things get a little foggy. In the most recent article, I suggested design depends on user-centered research. In spite of businesses hoping to “hire away” the problem (by hiring seasoned professionals who already are familiar with the problem space), the realities are each problem space may have curious and idiosyncratic opportunities leading to highly innovative and profitable solutions. If we don’t engage in direct research we run the risk of solving the wrong problem.  What is the equivalent to this research process in the domain of Software Architecture? I don’t know the answer, but I suspect there is no clean analog and I suspect here is where we diverge from our engineering cohort.

The flash of insight from my conversation with Brian centered around the notion of “patterns.” In my mind’s eye I saw how Software Architecture establishes various views into the system, decomposing the components from a high level down through software patterns ultimately leading to specific classes and interfaces. This description suggests the process of defining a Software Architecture is straightforward and mechanical. In practice the process takes multiple iterations, many false starts and a lot of imagination, qualities the process shares with User Experience Architecture. But beyond these general attributes (part of any large-scale definition effort), the two have very little in common.

For example, to the best of my knowledge there are no analogs to the notion of “patterns,” “classes,” or even “interfaces” in the context of User Experience. If the very definition of Software Architecture incorporates these concepts, and they don’t exist in User Experience Architecture, the two can’t be comparable. 

It appears to me then, using Software Architecture as the analogy to building a User Experience Architecture is fatally flawed, most likely because the two start from completely different assumptions: Software Architecture is fundamentally an engineering problem; User Experience Architecture is fundamentally a design problem.

In the next article, I will make another attempt at defining User Experience Architecture deliverables by starting with bricks-and-mortar architecture.

Posted by leofrish at 10:05 am
May 7, 2009

Architecture and User Experience (Part 7b: Getting to Know the Problem)

In last month’s article on this topic, I raise the specter of user research: how much is necessary and how much is enough? Different organizations have different thresholds for the amount of research they can tolerate. Lightweight research methods are often sufficient to capture the “low hanging” fruit, not because they are incredibly efficient but because many of the products and services we are called upon to fix are riddled with easily discoverable problems.

I continue last month’s questions: What is the right amount of time to spend researching versus “getting it done?” How can we know when to turn our attention to the solution and stop collecting “just a little more data?”

Is Ethnography the Answer?

Ethnography has been bantered about as a form of design research quite a bit lately. While many ethnographers are pleased at the uptick in business, an equal number express uneasiness about the casual use of the term. Ethnography is as much a process of investigating the culture of a target population as it is a framework for compiling and reporting the results. It is about telling individuals’ stories from their perspective within their framework. In highlighting how people inter-relate within an ecology, ethnographers help reveal the joys, delights and attractions of the ecology as well as its gaps, problems and opportunities for improvement.

A Simple Case Study

When observing a telephone technician struggling to identify the source of an alarm in the network operations center (NOC), seeing the adrenaline rush, and realizing, with him, that every second lost is lost revenue, unhappy customers and a possible investigation by a federal oversight agency, we feel first hand the real issues at stake. Prior to that moment, I had no experience with operating a NOC, and had only heard second-hand from others in my company what challenges these people faced. Nothing my cohort had said could inform me of the reality of that moment and the design constraints it implied.

When the moment passed, and calm had returned, I could ask simple questions about what I had just observed. The technician’s words were important to hear first-hand, but equally important was to read his face and gestures, to capture the continuing echoes of that event. Suddenly I understood the aftermath of the event was as important a moment as the “heat of battle”—there were things to be done after the crisis with impacts nearly as disruptive as the crisis itself. Here again, my office mates couldn’t have provided me with the key insights I acquired merely by being present and observing.

Most businesses don’t invest heavily in ethnographic techniques and for good reason. To do ethnography justice takes time: from several weeks up to a year. Instead, a form of applied ethnography, contextual inquiry, has been proposed as a much more efficient, cost-effective means of capturing similar data.  In fact, contextual inquiry can be an excellent quick-and-dirty approach to identifying low-hanging fruit and relatively obvious opportunities for improvement. Since most business environments are fairly inhuman, and the tools used in business are mostly not designed with their users in mind, quick-and-dirty techniques can easily reveal potentially profitable opportunities. In other words, we don’t have to be incredibly precise or gather longitudinal data to identify gaps sufficiently large enough for the business to profit from.

Simply observing, listening, and asking open ended questions reveals far more about a new ecology with far less cost than any other method I’ve encountered. When questions are framed not by the preconceptions of the product developers or business owners but by the users themselves, we have a far clearer idea of the real challenges they face. When I am asked to talk about the process of observation and the kind of data it generates, I like to pose a thought experiment to my listeners:

Imagine you’ve been asked to improve the experience of getting to your work from your home. (Imagine for the moment your place of work is outside the home). Imagine you’ve been asked by the marketing department to help them craft a survey of 100 people.  Now try to imagine the questions:

  1. If you drive to work, where is your car parked?
  2. Do you take the keys off a hook, out of a bowl, or do you keep them in your coat or purse?
  3. When you open the door, do you slip your briefcase in the back, on the passenger seat, or do you use a backpack?

Silly as that seems, most of the surveys I’ve seen attempting to isolate key factors for improving an offering are about as ridiculous. Okay, now imagine an alternative: I will identify a handful of key individuals and I will accompany them on their way to work for several days in a row.  I am confident the amount of data I gather in that short time frame with those few individuals will be far more actionable, reveal far more opportunities for improving the experience, and most importantly will narrow the field of inquiry far more efficiently than any statistically significant survey tool.

This isn’t your ride to work—it’s theirs. It isn’t your experience you’re trying to improve, it’s theirs. To be able to improve your audience’s experience, you have to first discover what (if anything) is wrong with it from their perspective.

Framing the Results

Observing a new ecology with a fresh mind is crucial, but that doesn’t mean we can completely erase our prior experience or deny our motivations and intentions. In fact, it is crucial to keep those goals and objectives “in mind” as the observation proceeds. Consider the above thought experiment in the following contexts:

  • You’ve been asked to design a mapping system for commuters
  • You’ve been asked to design a car entertainment system
  • You’ve been asked to design rain protection gear
  • You’ve been asked to design a new community

We would be foolish to ignore these design intentions even as we are observing the ecology. Random bits of data we might ignore or discount may catch our eye in the context of one of these design problems. Similarly, the same observation might have very different implications for one design problem over another.

The key is to engage the experience with a beginner’s mind influenced by the project’s design intention.

If we expect to create User Experience Architectures, we must expect to take an appropriate amount of time to do our research. If we are breaking new ground and truly investigating new ecologies of use, we can expect to spend more time up front in research than for ecologies with which we are familiar.  We are obliged to educate our clients about the importance of this up-front time, the deliverables we expect to come out of it, and most importantly, the profitable impact those deliverables will have on reducing our costs of development and improving customer satisfaction.

UX Architecture as the Vision Statement

At the time I was asked to get moving along on the solution and stop the research, I had already completed the research phase several years prior. As it turns out, this organization was not only unfamiliar with the methods I had used for research, they were fundamentally unfamiliar with the process of design. Without a proper understanding of the vocabulary of design, without experience with the deliverables of design and without a fundamental belief in the transformational power of design, they couldn’t bridge between the deliverables and a course of action. 

As in any profession, Architecture and design use specific tools for communication. In many cases these tools are not meant to communicate with non-designers at all, but to facilitate collaboration among designers. It would be facile to say my audience “just can’t understand” if they aren’t designers, but that would only underscore my failure of communication. I should understand my audience in such a way I can tell a story they will appreciate and internalize. How do we communicate the results of our work in ways that others can understand? 

I learned a fundamental lesson in all of this: if nothing else, UX Architecture is a vision statement of the problem and potential solutions wrapped up into a comprehensive and comprehensible package. The vision must be framed in the context of the audience for whom it is intended, describing an ecology of use as recognizable as it is innovative.

Over the next installments I describe the parts and pieces of a User Experience Architecture as they relate to our stakeholders. In addition, I provide a UX Architecture meta-model to help categorize the various deliverables we create.

Posted by leofrish at 5:00 pm
April 23, 2009

How do your designers and developers work together?

How do designers and developers work together in your organization? My colleague, designer Jonathan Follett (Hot Knife Design, Inc.), and developer Dan Pickett (Enlight Solutions) are conducting an online survey of the design and development community in advance of their joint presentation at Refresh Boston on April 29th, 2009.

Here’s what they say:

How do your designers and developers work together? As a small cooperative of designers and developers, we’re studying the processes and best practices we’re all using. Our findings will be presented at Refresh Boston on April 29th, 2009. We will also share our findings online after the presentation.

Please help us out by donating 5-10 minutes of your time and expertise to this survey.

Here’s the link:
http://enlightsolutions.wufoo.com/forms/design-development-process-survey/

As our own upcoming program (“Making Sense of User-Centered Design and Agile”) and workshop (“All Together Now: Blending Interaction Design and Agile Development Techniques”) demonstrate, there is certainly a lot of current interest in making two of our industry’s most successful processes—Agile Development and User-Centered Design—work together smoothly. We’ll have to await the results of Dan and Jon’s survey (which they have said they intend to publish sometime after Refresh Boston) to get a clearer picture on whether or not people in our field think that this blending is working or not.

In the meantime, please take a moment to participate in the survey yourself, or learn more about their presentation, “Making Agile Work for Design.”

Posted by MattHolm at 2:33 pm
April 2, 2009

Architecture and User Experience (Part 7a: Getting to Know the Problem)

I have been accused of many things in my career, but perhaps the most ironic and amusing was when I was told recently I had to stop focusing on research and turn my attention to making things. The irony is that I have always viewed research as the means to an end, not the end itself. In brief, I much prefer to get right down to Solving The Problem. Within my organization, even the limited amount of research I was pursuing was becoming difficult to justify and I was being directed “to get something to market.”

This job isn’t that different from others I’ve had in terms of how the organization values research. Research is a luxury; businesses hire seasoned professionals with the expectation the individual brings prior knowledge to the task, reducing further the need for “expensive” research. Other disciplines around me limit the types and focus of their research. For most of the engineering staff, research is limited to either scanning the trade magazines reading about recent trends in the technology du jour, or looking for specific technologies to solve the problem at hand.  For the marketing staff, research often means rapidly collecting aggregate data about competitive offerings, feature rankings and pricing.

I was more than amused to note the time I spent on research had passed the organization’s tolerance, when, from an objective standpoint, it was as close to a minimum I could imagine pursuing. What is the right amount of time to spend researching versus “getting it done?” How can we know when to turn our attention to the solution and stop collecting “just a little more data?”

Seeking Truth versus Seeking truths

I think about those questions every time I sit down to consider a new project. Do I have enough information to make a compelling solution? Do I understand my target audience well enough to judge any alternative as better than another? How confident am I in proposing a solution, especially if it is disruptive, expensive or otherwise foreign to the current direction of the organization? In general, if I’ve been asked to participate in designing a solution, it is likely because the problem is intractable and the solution is neither obvious, self-evident or cheap. 

The thought that I was spending too much time on research and not enough time fashioning solutions forced me to reconsider what my organization’s values were.

I am unapologetic about using research as a means to solve problems rather than to explore the human condition. I recall my roommate in graduate school whose ambition was exactly the opposite: using research to simply further a business goal seemed cheap and easy; far better to discover underlying principles that would further the knowledge of the species.

I am happy to let the seekers of Truth expand the human knowledgebase through careful experimentation, large-scale observations and years-long endeavors. I am not a seeker of Truth, but rather a seeker of truths, those things that are likely to be true in a given context at a given time, but may not be reflective of a larger Truth about the human condition. Design is applied art; it depends on a patron, its success is judged by how well it works within an externally provided framework (the market, the user base, the patron’s arbitrary needs, etc.), In finding small truths, I believe my designs are more suitable to the immediate context for which they have been commissioned. 

Data Driven Design

Fairly early on in my career I learned I liked to get things right.  In pursuing solutions for clients, I discovered my imagination, powerful as it might be, was just as likely to get it wrong as it was to get it right. Imagination and excellent craftwork are insufficient to get things right, no matter how intuitive the designer. Without an empathic understanding of the target problem space, the designer is at best delivering Art, and at worst, junk. Creating an “elegant” design (balancing the three Vitruvian principles firmitatis utilitatis venustatis, translated roughly as strength, utility, and beauty) means incorporating the sensibilities of the individuals for whom it is intended. Assuming design elegance is defined in Vitruvian terms, provocative questions remain: whose definition of utilitarian or beautiful should we use, our own, or the users of our offerings?

I no longer take great joy in simply making things up—the lack of constraints is fundamentally unsatisfying—I prefer to respond to clear and present needs of a target audience.

For me, crafting a solution to a problem rooted in a target audience’s experience is far more satisfying than creating arbitrary forms. Finding a problem set previously undiscovered or not yet addressed by existing products is as close to exhilarating as my life gets these days. (I need to get out more). Finding solutions to those problems is even more delightful.  But best of all is witnessing users enjoying those solutions.  Knowing (with a high confidence in advance) my proposed solutions will be embraced, is sweet.

The point is, research is not a necessary evil, it is the key to identifying the problem space in which a solution will be found. Obversely, research need not be driven to academic proportions: in business, seeking truths is far more relevant than seeking Truth. 

User-centered Research

In a previous article I discussed agile methods of eliciting user reactions as a way of reducing costs and illuminating real needs. In many circumstances, agile approaches can be very cost effective, but in other cases they fail to identify world-class breakthrough ideas. In the most recent article, I mentioned the hazards a business faces as it attempts to enter a completely new “ecology of use.” Without self-consciously reconsidering its current offerings in the context of the new ecology, a business will likely fail to capitalize on the opportunities to be found there.

Given how easy (and inexpensive) it is to find opportunities in a new ecology, it’s almost a crime businesses fail so badly at it. The key to the process is to stop “selling” and start “listening.” Put another way, the key to the process is to stop “knowing” and start “observing.” Another way to put it is to approach the new ecology with “beginner’s mind.” I remember my father, when he gave sales trainings, saying: “Your customer doesn’t really care about you, your product or what you’re selling. He’s all wrapped up in his own problems. Figure out how you can be a solution to his problems, and he’ll sell your product for you.”

We are often so wrapped up in our preconceptions of our users’ world we fail to see opportunities for elegant solutions. We think the answer is in a website, an enterprise product, or a new piece of hardware. Maybe it’s none of those things; maybe it’s just a minor but significant change in a process. In a commission for a remodel of a bathroom I was asked to resolve a problem with damp towels. As I listened to the owners describe the issue, standing in their existing bathroom, I observed how the towel rods were mounted, their length and so forth. They suggested I research heated rods as one way to solve the problem. Instead, I presented a design in which the towel rods were lengthened and positioned closer to the heating vents. I then suggested they fold their towels differently to allow them more surface area to dry. It wasn’t very “sexy,” but I was able to use the money saved on unnecessary technology to improve the design elsewhere.

My process (and from what I can gather from other practitioners, a process that supports world-class results) depends on deep, empathic understanding of the individuals who are intended to use our offerings. Without a basic understanding of our users’ environments, artifacts, power relationships, goals, aspirations, hopes and dreams we are unqualified to make relevant and long-lasting design decisions.  It is our job as User Experience Architects to impress on our managers and our organizations the crucial need for this deep understanding if our offerings are to measure up to our expectations.  As it turns out, and as I’ll discuss in the next article, getting to this level of understanding is not expensive and does not require an army of highly trained individuals.

Posted by leofrish at 1:35 pm