Category Archives: Web design and technology

Posts on technology and design, in general.

UX and Project Mangement cross-over article from Interactions magazine

Posted on by
Reply

A Taxonomy of Models Used in the Design Process by Joanne Mendel in the Jan + Feb 2012 edition of Interactions magazine is pretty interesting.

At Covenant Eyes we’re continually in the churn of Agile development, and integrating user experience work can be challenging. We’re figuring it out, and have definitely made some breakthroughs, but this article has provided another perspective that is helping me think about timing of user experience work within the loose phases of work that a typical project runs through.

It isn’t a stretch to layer the phases of Discovery, Reframe, Envision, and Create over a project’s lifecycle, and so tying different models for design work in each phase provides an opportunity to reflect on how we’re doing with matching up appropriate design work.

I’m asking my team and our project managers to read through it, and perhaps we’ll get a chance to discuss it together and consider if we can use some of the ideas to do better work.

How I use utm_source, utm_medium, utm_campaign from Google Analytics

Posted on by
Reply

My friend Adam called me this evening to ask how I’ve used the Google Analytics tracking codes utm_source, utm_medium, and utm_campaign. He’s working on an app to help marketers generate HTML e-mails, and is thinking about automating the inclusion of these tracking codes.

The utm_medium is pretty straightforward in that the medium would be values like email, web, twitter, rss, and so on.

But, what’s the difference between utm_source and utm_campaign?

Google’s documentation on these variables is helpful in general, but is not all that clear on the difference between these two variables.

So, here’s how I think of those variables. The utm_source is like a noun, and utm_campaign is like an adjective. The utm_source will be more consistent from one edition to another, while the utm_campaign will change.

Let’s look at an example. Let’s say I send an e-mail newsletter called Brilliant Widgets every season (Spring, Summer, Fall, and Winter), and I want to track how many links back to my website each edition generates. Here are the utm_* values I would use.

utm_* values for the Winter edition of Brilliant Widgets

utm_source Brilliant_Widgets
utm_campaign Winter_2011
utm_medium email

So, the href value of the link back to my website would look like this: http://blog.davingranroth.com/?utm_source=Brilliant_Widgets&utm_campaign=Winter_2011&utm_medium=email

Now, assuming I use those parameters on the links back to my website and that my website activity is being tracked with Google Analytics, I’ll be able use Google Analytics to identify website visits that came from that e-mail newsletter. Then for the next edition, I would keep utm_source and utm_medium the same, but update to utm_campaign=Spring_2012.

With this thinking, you could define a set of values for all the e-mails you send out, and create a system that would help you know what those values should be when you introduce new online publications.

I’m sure that other people and companies have come up with their own approaches to using these utm_* values.

I’m curious, does anyone else have different ideas or examples to share?

Does Kanban hurt Agile teams by decreasing iterative development?

Posted on by
3
Workers welding on an automobile assembly line.

Kanban/Lean manufacturing makes sense for factories. I'm not sure how well it translates to web and software development.

Kanban is a balm now being used by some Agile development teams to soothe the pain caused by timeboxed development cycles. Jeff Patton’s statement, “Short timeboxes herniate,” sums up that pain (from his excellent post “Kanban development oversimplified”). As a Product Owner with a team that started out using Scrum and has gradually drifted to something else, I identified with all those critiques of timeboxed development.

Management expected the team to deliver user stories every week because our iterations were week-long. So when the team realized at mid-week that they wouldn’t be able to deliver a story by Friday, the team would pick up a small bug to fix just to show something by week’s end. That’s a problem. As a Product Owner I saw this mid-week “save” for the sprint review as pure distraction from more important work. So we dropped the weekly delivery requirement.

When I read Jeff’s article, I realized that the way we were working looked more like Kanban than it did Scrum—except we were still using Scrum words and concepts to discuss and analyze our work. Words like “iteration”, “sprint”, “daily scrum” no longer fit.

As a team, we had let go of the expectations of a sprint, and we were still delivering great value, just on a more natural timetable. I believe our efficiency stepped up when we ceased adhering to the rules of Scrum.

However, because we still spoke in Scrum phrases, our company had not followed-suit. Frankly, without a name and model for what we were doing, we weren’t sure ourselves.

Months have passed since then, and some Kanban ideas have seeped in to our work. But we haven’t embraced any change, really.

Why change? Despite the problems I’ve alluded to, the team is really doing great work. They are delivering value to the company and its customers. So one argument is to simply continue on our course. The other is that we’re already practically doing Kanban, so why not start using words and tools that match?

In my brief review of Kanban, I see that it comes from the Lean Manufacturing philosophy. How it is being used in the Agile world is really taking Kanban as a metaphor. It is adapting a model from the manufacturing world and applying it to the software development world. I’m naturally wary, and so want to critique this adaptation for the sake of clear-headedness.

First, let me admit that of all the Agile flavors, Kanban seems the most practical to me. I’m a fan. That said, software development is not an assembly line. We don’t deal with pre-designed units like car doors. Instead, we have a variety of problems and need to be able to design a system to appropriately handle whatever those problems happen to be.

Whereas Kanban works well for an assembly line that puts the cars together, software development looks a lot more like the design shop that engineers and prototypes new car concepts or revisits problems with existing cars to make them more efficient and safer for the next model year. Sure, we produce applications, but a whole lot of the work is really design work.

Design work tends to be iterative and recursive, but I don’t see words from Kanban that support iterative work. In general, a card moves from left to right across the board. Sometimes, the card ought to be killed and restarted with the  ideas we’ve learned during it’s first round. However, from what I see of the Kanban model, this just doesn’t happen. (Not that is happens in Scrum either.)

Why is that? Maybe it’s because coding is expensive and we suffer from the sunk-cost bias. That seems like flawed thinking.

Maybe, as I wrap up this half-thought-out post, I’m simply frustrated by the lack of deep design work in our projects.

More later. I’ve been thinking of the design process with insights from some recent research and articles seen via SIGCHI, and it may result in some design management postings.

Anyone else have ideas to share here?