During this past July’s Agile UX Retreat I had the opportunity to speak at length with Michael Long from ThoughtWorks about staffing and managing projects with poly-skilled team members. Our conversation tickled many of the concerns I’ve had with building project plans that separate and too specifically define design and development roles.

Atomic has a strong agile development culture and employs both designers and developers. We started as a development company and used to partner with design firms frequently. We started hiring designers in order to better control design capacity on projects. When we used to partner with outside firms, significant amounts of design would be done up-front and the designers would not have the opportunity to be stewards of their design during the development phase. Often times, design challenges would be discovered during the development effort and the partner firm could not be responsive due to their capacity commitments on other projects.

Having designers in-house offered many opportunities but also posed new operational and project management challenges. At a company level, we decided to manage design capacity separately from development capacity because we wanted to optimize design for responsiveness instead of throughput. We thought designers would be touching many projects throughout any given week. On projects, we tried keeping design backlogs separate from development backlogs because we suspected that development would always be the bottleneck on any project given a sufficient iteration zero.

It seemed natural to consider and manage design as a distinct role. Design is different from development so more management time, process and tools would be necessary to integrate designers with development teams. Right? That line of thinking makes me uneasy. Our development teams have historically been able to use simple tools to manage project scope and forecast project cost and completion time. I’m not convinced that adding designers to programming teams necessitates a project management overhaul. After speaking with Michael, I’m convinced that staffing and managing teams with poly-skilled members is a key to keeping project management streamlined and straightforward.

Please follow along in the coming weeks as I share my thoughts and experience on managing agile design and development projects.

Ideas for upcoming posts are:

• What makes a poly-skilled team
• Design lead and lag, shifting bottlenecks between design and development
• Managing for efficiency or effectiveness
• Integrating design and development backlogs

Don Norman writes about why Simplicity Is Not the Answer

If my cellphone only had one button it certainly would be simple, but, umm, all I could do would be to turn it on or off: I wouldn’t be able to make a phone call. Is the piano too complex because it has 88 keys and three pedals? Should we simplify it? Surely no piece of music uses all of those keys. The cry for simplicity misses the point.

The language that we as UX practitioners use to talk to each other isn’t always useful to our customers. Author David Sherwin suggests having a cheat sheet for talking to clients about the business value of UX and shares his own cheatsheet as a guide.

Can You Say That in English? Explaining UX Research to Clients

As much as I’d like to tell my clients to go read The Elements of User Experience and call me back when they’re done, that won’t cut it in a professional services environment. The whole team needs a common language and a philosophy that’s easy to grok.

I created a cheat sheet to help you pitch UX research using plain, client-friendly language that focuses on the business value of each exercise.

A design student, Pascal Raabe has created a very nice tool summarizing the definitions, techniques, and roles of User Centered Design. It’s available as a free download as a jpeg or pdf. Alternatively, for a donation, it can be printed and shipped.

Did I mention that it includes penguins?

User Centered Design Infographic Poster

The central premise of user centered design is that the best designed products and services result from understanding the needs of the people who will use them. -Design Council

I’m a Graphic Design student about to go into my third year at the University College Falmouth. During a year of self-directed study I had the pleasure to work with many interesting design studios and practitioners which got me interested in user centered design.

Although I know that this diagram is by no means complete, I believe that it can be beneficial for students and design practitioners in various disciplines. I release it under a CC BY-NC-SA license with the hope that others will find it a useful tool for learning or teaching and to share and build upon…

This is an information graphic poster illustrating the underlying lifecycle, methods, principles and techniques in a user centered design process where the visual part is only the tip of the iceberg.

A Shared Vision for Product Design & Ownership

"Real artists ship." - Steve Jobs

As a working software designer there is no more exciting, relieving, and depressing moment than the moment you ship a product you've been working on for months. With each client I work with and each product I work on I invest myself fully. The product becomes “our” product.

If all goes well we've worked together to define features, craft experiences, and empathize with end users. We've settled into a shared vision, vocabulary, and collection of dreams for the product. Together, we've given birth to something new.

Giving that “something new” up for adoption isn't easy. Even if the client was a fully-engaged parent. Especially if the client was a fully-engaged parent. It’s these clients who will take a project and continue to push it forward even after the original designer has moved on.

The Agile development process used at Atomic Object encourages fully-engaged clients who are intimately involved in feature definition, prioritization, and the rest of the design process.

These clients are most often a dream to work with. They care, they're invested, they're informed and can contribute their depth of domain experience. And having been involved in the design process from day one they rightfully feel a sense of ownership in the decisions that have been made. They have been, and will remain, the product owner no matter how much I—as a designer—invest of myself into “our” product.

Features will be added, usability issues will be addressed, and new vision will be discovered. If the product is any good the product will change. This is not surprising and should be encouraged. The disappointing part of this is not that the client takes ownership but that some clients will mistake their intimate involvement in these decisions for design.

After launch it becomes much easier to just add this feature or that page. The shoe-horning doesn't become an issue immediately. But ad hoc features grow like weeds and if left untended can choke a product before it has a chance to succeed. In more extreme cases they can even drive away users that have already chosen the product and begin a much slower, but still dangerous, reverse tide (see Facebook's current privacy woes).

Product owners always have a hand in the design process, and even more explicitly in an Agile team. So, it is important for me, as a product designer, to help them find and begin to use a set of feature management tools that will keep “our” baby alive.

Unlike most traditional print designers, as a software designer I’m setting foundations for a product that will continue to evolve over time. And that evolution is bound to happen at a much faster rate than that experienced by other types of product or identity design. The digital world moves—and moves fast.

These foundations begin with practices that will help product owners nurture sustainable design and avoid the kind of post-design feature creep that can eventually poison the bottom line.

Here are five practices I try to follow as a product designer and teach product owners to take ownership of as they continue to move forward:

1. Ask The Five Whys

   When considering a new feature for your product consider The Five Whys. Question your feature until you’re absolutely sure that it should be added. Remember it’s much harder to remove features than it is to add them.

2. Ask Five More Whys

   If you begin by describing your feature with either of the following phrases, “It’d be cool if ...” or “Users have been asking for ...” consider asking five more whys. Both of these can be easy paths to a diluted vision. While users are important and they often think they know what they want, their vision is most often narrowly defined by what they have experienced in the past. You want your product to be focused on the future.

3. Have an Opinion

   Good product design has an opinion and usually a strong one. Only add the features you can fall in love with—the ones that seem essential to the identity of your product and make you want to get up in the morning to see if they’re finished.

4. Say Sorry

   It can be exceedingly hard to do, but sometimes you have to remove a feature or two. Be very cautions but unafraid to kill features that undermine your product. Sometimes you just have to say, “Sorry.”

5. Avoid The Creep

   There is nothing that can help you keep your product vision alive and well like awareness. Never cut corners or say yes too quickly when considering new features. Continuing to ask yourself and your team the hard questions will be key to staying on point.

Designing with film:

In these experiments we designed and invented spaces, objects, movements and audiovisual techniques that map and visualise the interactive phenomena of RFID. Many of the visual/cinematic concepts for Nearness and Immaterials were invented by exploring and experimenting with film.

Rather than investing time in creating complex software and hardware prototypes, the interactive experience can be quickly explored inside film compositing applications. These experiments have shown us that there is great value in having tools that offer efficient prototyping of interactions at an experiential level, that don’t need to rely on complex electronics or physical design. There is also value in working within a medium that is not tied to a specific location or a unique demonstrator, and that is editable, reproducible and transmissible allowing it to be shared freely and widely amongst a research group and across the internet.

The sample videos, in my opinion, aren’t particularly compelling. That said, the essential idea itself has a good deal of merit—use digital video and post production tools to mock up concepts, interactions, and experiences.

Post production video tools are powerful. Design experiments in video could provide rich, meaningful feedback and move far beyond 2D, static mock ups. Creating the video itself is an exercise in working through the essential design challenges. Because it’s video there is opportunity to confront issues like transitions and movement of elements that is difficult to do with static mock ups. Using this approach could apply equally well to user interface development and physical product design.

Matt Legend Gemmell on Engineer Thinking:

All too often, when faced with a decision about how to implement certain functionality, engineers take the extreme position that:

1. A feature must be exactly what 100% of users want.
2. If the above isn’t true (and it almost never is), the feature must be configurable.

This binary approach is gravely wrong, and unjustly offloads decision-making onto the user of the software. We’ve all seen where this approach ends up: multi-row sets of tabs, scrolling panes of checkboxes, nested radio-buttons and a general overload of configuration.

Matt Linderman (37signals) saying Computers shouldn’t make people feel like idiots:

For those of us surrounded by the minutiae of computers all day, it’s easy to forget there’s a world of people out there who just don’t get it. And it’s not their fault. It’s ours.

Mike Monteiro (Mule Design Studio) on The Failure of Empathy:

As an industry, we need to understand that not wanting root access doesn’t make you stupid. It simply means you do not want root access. Failing to comprehend this is not only a failure of empathy, but a failure of service.

(via ignore the code)

Last weekend I had the privilege of attending a UX Agile Retreat at Cooper. The retreat was an informal event where ~33 practitioners from the UX and Agile fields came together to discuss how we can better create effective and successful products. The event schedule was loosely defined and it self organized based on the trending topics. We used a variety of exercises and discussion techniques to voice our experiences, concerns and ideas to help build a vision of a better, collaborative future.

Where We’ve Been

The UX and Agile communities have been flirting with how they could integrate their practices more seamlessly and respectfully. Both groups respected one another yet remained uneasy about having to alter their respective approaches for an integrated vision and process. UX Designers were worried that some of their practices would be minimized or marginalized due to Agilistas’ strong belief of minimal upfront design. Fear existed that quality design would be sacrificed to the almighty iteration once an agile project was underway. Agilistas were worried about designers doing too much work up front without creating functioning software. Developers were ignorant of the UX Design process and the immense value it provides. Individuals, like Jeff Patton and Lane Halley, have been working very hard to increase knowledge and respect between the two groups. Anders Ramsey organized and dedicated himself to making last week’s event happen. He did an outstanding job. The UX and Agile camps are coming together because they recognize and respect each other’s dedication to the craft of creating high quality products.

Where We Are

Most of our discussions during the retreat focused on vision, values and principles instead of outlining a strategy for collaboration. I’m glad the group was able to remain focused at such a high level because good process stems from alignment and a mutually shared vision.

We took a stand that the “Us and Them” mentality is dead and that we have to move forward as “We.” Management and business processes have kept our groups apart in the past due to a focus on efficiency and a misunderstanding of what it takes to create successful digital products. Management often times does not know how to ask us for what they want, nor do they know how to properly manage creative teams. We believe that we can create better products more efficiently by focusing on being effective. We believe that effectiveness is increased by working together closely.

The Future

The new vision is forming. The retreat group is committed to evangelizing and furthering this vision. I left the retreat with strong feelings of alignment, momentum and excitement. We are the makers of amazing, complex things and we are taking a stand on how we’ll bring the dreams of others into the world. We’re building a case for businesses to employ design thinking at all levels, to focus on the satisfaction of their customers and and to let individuals who understand the creative process to manage it for effectiveness.

Jeff Patton and Lane Halley ran an Agile UX workshop for Atomic Object recently. One part of the workshop was the practice of user and stakeholder research through interviewing. For the exercise, we used a speculative development project that we’ve been researching for six months. We interviewed our office manager, Mary O’Neill, as the basis for one of the main personas for the project.

I didn’t expect to learn much from this interview about the project itself. After all, I’ve been thinking about this project, researching the opportunity, discussing it with many people, pitching investors, collaborating with our partners, and generally immersing myself in it for the last six months. On top of that, our office manager is also my wife, so I live with the interviewee and know very well her habits, goals and objectives concerning the subject of the project. How much more could I learn from a 30 minute interview? Lots, it turned out.

Interviewing Mary to craft a persona representing a user of the application we’re building turned out to be a rich vein of insights, surprises, new ideas, concerns and hidden opportunities. This experience brought home the value of the pair interviewing technique Lane taught. It also furthered my resolve to help our clients understand the value of this research. Learning so much, with so little effort, on something I already knew so well – how can this not be part of every project we do?

Over the last 18 months, Atomic has made significant growth in our product development services. We now kickoff most projects with an initial discovery and design phase. In this phase we grow our understanding of the client's domain and their vision of the software they want to build. We create artifacts like financial models, personas, wireframes, visual mockups, prototypes and release plans. Eventually, we create a backlog of estimated stories that the development team can start implementing in the development phase.

A few developers at Atomic have shifted into a UX role. We've been growing the company's awareness of UX and product development practices. Last Thursday and Friday Atomic held an in-house UX workshop led by Lane Halley and Jeff Patton. The workshop exercises focused on a speculative development opportunity Atomic has been considering.

Thursday morning started by Lane and Jeff asking what we wanted to get out of the the workshop. They built a backlog of objectives for the workshop and included what we wanted to learn.

Once the schedule was set, we started by talking to the project's stakeholders about their general ideas for the project. Lane and Jeff gave a sample stakeholder interview with one of the stakeholders. We were taught some interview techniques and had the opportunity to practice interviewing with partners. We had some interview candidates lined up for the afternoon so we put together an outline of interview questions.

After Thursday's lunch we slimmed down to a smaller group. This group refined and organized the interview outlines. We conducted four interviews as pairs while the rest of the group observed. We had a retrospective after each interview where we compared notes and critiqued the interviewers.

On Friday the whole company came back together and the interviewers shared their notes. The notes were taken on cards. The cards were laid out and grouped together based on observational similarity. We constructed provisional personas (obviously real personas would require more research) from our notes. Each persona had a name, attributes, objectives and values. We broke out into teams and constructed context scenarios for each persona.

After Friday's lunch, Jeff had our product stakeholders define their high level business goals. We discussed what would constitute success. The discussion gave us insight into what kind of metrics the software may need to provide.

Then Jeff asked how we define a user story. This was a rich discussion that gave us insight into how much we have internalized user stories and how the simple definition of a story has changed over time

After our user story discussion, we extracted activities from our context scenarios. Jeff led us through an exercise where we created a story map. We organized our activities and derived stories from the activities. We looked to the project stakeholders for story validation. We then engaged the stakeholders in release planning using the story map. The exercise showed a great way to prioritize high level stories before fully defining the details required of a finer grained story to be entered into a development backlog.

The workshop ended with a retrospective where the entire company asked questions and shared thoughts.

I'm very excited to see Atomic continue to grow in our UX and product development practices. We've stayed at the forefront of agile development and management for some time. While there, we saw that our clients needed help in formalizing what their project was, who it was for and what business value it would provide. That need and our drive for excellence has pushed us forward to better help our clients. We are enjoying the ability to provide the necessary up front services that ensure we are developing successful products.

Over the past few months I have been involved with the development of uladoo.com. Uladoo is a small, in-house, collaborative web project between Atomic Object and David Christiansen. Uladoo provides a simple means of creating, updating and sharing charts for people who desire to track their daily activity. Uladoo uses Twitter for creating and updating charts.

David had the idea for Uladoo in the midst of a weight loss effort. He was already an active Twitter user and thought it would be convenient to be able to tweet his weight and have those tweets tracked.

I thought David's idea was interesting because he identified that Twitter could be used as an application's data source. At the time, most of the applications related to Twitter were on the surface of the Twittersphere, facing inward. Twitter clients, tweet management tools, and tweet analysis were all hot. These kind of applications were aimed at enhancing and organizing a user's Twitter experience. David realized that we could think of Twitter as a communication protocol to power Uladoo. Users could input their chart data through a multitude of Twitter clients and we could use the Twitter API to pull our application data.

Because this project was in-house, we had the luxury of being able to exercise our product design and development practices as we saw fit. We viewed the idea as experimental and decided to forgo user research. We decided to release a minimal product that was easy to learn, account free, and simple to use. If the idea took off, we'd develop it further.

Being account free was a curse and a blessing. During our discovery and design phase we kept identifying all kinds of complexities. What happens if a user tweets to the same chart twice in a day? What happens when they skip a day? What level of granularity should we display the data? We kept getting bogged down into the details and started to think that a user would have to provide preferences. We didn't want users setting preferences via Twitter because we thought that violated our principles of Uladoo being simple and easy to learn. Our principles forced us to make judgment calls and design the behaviour in accordance with our idea of the general case. Our self imposed constraints allowed us to move forward and not sputter out during the design phase.

We were able launch Uladoo within five weeks. We spent about a week in design and discovery and four weeks in construction. It was a great experience participating in a small, focused project. We're continuing to add features to Uladoo. After we had about 100 people using Uladoo, we decided to provide a 10, 30 and 60 day view of user charts. We just added a feature allowing users to embed a chart in their blog or web page. Check out the Uladoo Blog for updates on new development.

Shawn Crowley and I recently spent some time at Cooper in San Francisco. Among many interesting conversations during our visit, I had one of those “ah-ha” moments when Alan Cooper was describing his view of personas. I’d read all about personas before, including Cooper’s writings, and Atomic regularly uses them in our software product development practice. (Considering Alan is widely credited with having invented, or at the very least popularized, the use of personas, it might seem obvious that discussing personas with Alan Cooper himself would result in some useful learning. But as with all learning, I believe, it’s not about the teacher, it’s about the student.)

I have previously thought of personas as a source of information to inform and influence product design. Personas were an artifact of research, and a source of information to turn to when designing the information architecture, interactions, and features of your product.

The light bulb went off over my head (rather apparently, I gather) when something Alan said made me see personas as part of the design itself, rather than something you use to create a design. Put another way, personas aren’t research, they are design. When you’re identifying personas, selecting them, fleshing them out, editing them, and prioritizing them, you’re making design decisions for your product. What you leave out, or de-prioritize has as much impact on the design of your product as what’s left in. Who your personas represent, what they care about, what’s important to them—all of these decisions are product design decisions. Personas are some of the earliest product design decisions we make.

Outside of nestling personas more deeply and comfortably into my neural pathways, is this insight valuable? I think it is, and for two reasons. First, it helps you realize the significance of the activity you’re engaged in when developing personas. Even if you didn’t actually produce a persona artifact of some sort, you’re making critical design decisions that will impact the outcome of your product. (Or conversely, if you’re skipping this activity, and have no effective replacement for it, you’re flying blind with respect to what you’re building.)

The second reason it matters to recognize personas are design comes during the development stage of your product. Months into software development you may realize your customer or the product manager is steering the project into features that don’t in fact serve the design (specifically, the personas) you started with. This might be good, or it might be bad, but it sure seems like an interesting thing to give some consideration to. Software development is such an expensive activity that it’s irresponsible to do unless you have a good idea of where you’re going and what you’re building. Keeping your personas around as regular touchstones will help you realize whether you’ve left the original design behind, and help you have that critical conversation with your customer, if so.

Bill Higgins draws an interesting parallel between the ideas of The Uncanny Valley in human-like robot design and user interface design. He makes an argument for why web apps should look and act like web apps and desktop apps should look and act like desktop apps. He even offers interesting thoughts on why Java never took off on the desktop.

“The Uncanny Valley of User Interface Design“

”... we must ensure that we design our applications to remain consistent with the environment in which our software runs. In more concrete terms: a Windows application should look and feel like a Windows application, a Mac application should look and feel like a Mac application, and a web application should look and feel like a web application.”

“So I’d recommend that if you’re considering or actively building Ajax/RIA applications, you should consider the Uncanny Valley of user interface design and recognize that when you build a “desktop in the web browser”-style application, you’re violating users’ unwritten expectations of how a web application should look and behave.”

I had the pleasure of attending the IDEA Conference last week in Chicago. IDEA is sponsored by The Information Architecture Institute and is an annual conference about "Information: Design, Experience and Access." This conference was very timely for me as I have been moving into a product development role at Atomic that is more focused on product design than software development. Although IA encompasses only a part of user experience design, I have found that most of my user centered design efforts have been focused on building enough understanding about users to eventually model an information architecture that a client can approve and a visual designer can work from.

The conference was definitely thought provoking. I found most of the presentations rather abstract but there were definitely some practical connections made. Coming from a development background very focused on process improvement and toolsmithing, I was expecting to hear more about experience reports, metrics, and process innovation. I got the sense that day-to-day tools and techniques were covered in the workshop, (I was unable to attend the pre-conference workshop as it had sold out before I registered), and that conference was more of a forum to explore higher order observations.

I was very happy with conference overall. I was able to attend some very interesting talks and network with other professionals in the field. The conference was very well organized and I appreciate all of the hard work done by the volunteers and The IAI.

A Comic by Eric Burke:

via [stuff that happens]