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]

The blog post "How Cognitive Science Can Improve Your PowerPoint Presentations" discusses four ways cognitive scientist Stephen M. Kosslyn offers for creating more human brain-compliant PowerPoint presentations. The basic concepts, however, are likely equally helpful in developing user interfaces.

As mentioned in a previous post, we’re talking more and more internally about user interface and user interaction design. Just came across an interesting resource: the User Interface Design Pattern Library.