User experience, management, bullseye pistol, faith, and my family
Davin is Chief Operating Officer for Covenant Eyes, Inc. in Owosso, MI, USA, where he gets to mix his background in user experience design, research, and strategy with the operation of a software company. For more, see his LinkedIn profile.
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.
My current mattress is a little too soft for my bad back’s liking. And it’s just too big. I’m decidedly single at this point, have never been too tied to possessions in general, and so for me my queen mattress is just a nervous tick on the side of crazy. It’s time to downsize.
So, I wanted a picture of the relative sizes of standard mattresses to help me think through this. Tada, OmniGraffle to the rescue. Picture attached. (I realize they look like sticky notes. Mildly funny to me.)
Looks like a full-size mattress will be in my future.
Ah, the nanny tax. Some quick Google searches show a range of 80 to 95% of people who are obligated to pay the nanny tax, simply don’t. (NYTimes, ParentDish.com) That’s a pretty whopping statistic.
As I’ve been finding out, it would certainly be easier to just skip it. This past summer I hired a nanny for about six weeks. And, wanting to do the right thing, I decided I would deal with the paperwork and expense, and just pay her as a household employee and deal with the taxes. And that’s still the right thing to do.
But, wow, do I hate paperwork, and this stuff is over the top.
For the State of Michigan, I found out I have to fill out form 518, Registration for Michigan Business Taxes. The title of the form alone caused some trepidation. As I proceeded to fill it out, I found myself frequently scratching my head, thinking things like, “Why are they asking me about acquiring a business in the past four years? I just wanted to pay taxes for hiring a nanny.” Or, “But I’m not a business. I’m not buying or selling anything. This is a money losing scenario for me. I just want to pay what I have to for hiring a nanny!”
So, there was form 518, plus two additional forms I had to fill out, just to jump through some hoops to register for Unemployment Insurance taxes.
It’s pretty obvious that those forms are meant for real businesses, not private individuals who want to pay a household employee. I was so close to hiring a lawyer or accountant, but that just seemed unreasonable to me, so out of proportion with the fact that I just wanted to pay a nanny.
Upon having gone through the paperwork, nearly all of it was completely irrelevant. The relevant pieces were mostly my name and address or oddly specific. For instance, I nearly didn’t find the SIC number that applies to my situation. On the second page of SIC codes, about two thirds of the way down the fourth column of codes I found 881: Private Households – Domestic Employees, Cleaning, Baby-sitting, Private Nursing. I’m glad I found it, because I was really close to just leaving that field on the form blank.
Perhaps to the government, paying a nanny is just like owning a business. But, to me that seems like a dandy of a one-size-fits-all blunder. If instead the only form that a private individual had to fill out in order to register for nanny taxes was a quarter-sheet size form with contact information, perhaps more people would actually fill it out.
Maybe it could be a special edition of the 518, called 518-PH, for Private Households. The rest of the pertinent 518 information could be presumed on that form, simply because people filling it out fit that profile. (For instance, it would imply SIC # 881.)
How many people looked at the paperwork, freaked out for a moment, and then just decided to skip it? The current form is quite simply a roadblock to tax revenue and to people who would like to do the right thing.
Lately I’ve been thinking about formatting phone numbers. Of course, there are plenty of options in addition to the ones above, but these are some common ones, although the thin spaces option is perhaps not too common. I added it because I’ve been wondering about the value of the separator characters, and if we can just not use them in favor of a little white space.
Here is some of the thinking.
The conventional formatting of (123) 456-7890 will obviously be a phone number to most Americans.
I’m no fan of the dashes.
I’m okay with the periods. However, are they needed?
Which led me to try the version with thin spaces between each set of digits.
I like the thin spaces, but I don’t dislike the conventional version. So, for obviousness, I lean towards the convention. For aesthetic, I lean towards the thin spaces.
But part of the decision of which approach to go with will depend upon the context. For instance, is the phone number labeled with an obvious word like Telephone or Phone? If so, I might opt for the thin spaces version.
However, if the context is unclear, say in the absence of clear cues about what that number is, the conventional approach would be best. Otherwise, the number could be misinterpreted as some other number, or it might simply take the reader too much mental effort to recognize it as a phone number. No need for that sort of rudeness.
Clearly, this is all just my opinion. Do you have a preference for how phone numbers ought to be styled?
Each group organizes events for practitioners, students, and academics to gather together in order to network and learn from each other. It’s great!
But it is also a bit much to keep track of, and I’m not always clear on which group is sponsoring which event. After all, a great many people in the UX field do usability research and evaluation, interaction design, and are interested in research and theory. Thus, we tend to see a lot of overlap in attendees for events from any of these organizations.
So, during a conversation at work today, Caitlin, Alaina, and I hatched a rough concept. (Disclaimer: this post represents what I personally took away from that conversation. I invite Alaina and Caitlin to chime in on the comments below to correct my thinking and/or to add to this post.)
Here’s the gist: Loosely coordinate the efforts of these organizations by factors of geography, frequency, and approach to UX.
MI UPA is a state-wide association, so we hope that MI UPA events will be big enough to draw people from a wider area of Michigan. Of course, it is difficult to draw people from as far north as the Upper Peninsula (there are UXers up there, right?), but for a great deal of people in the state, an occassional drive to Lansing, Ann Arbor, Detroit, or Grand Rapids is acceptable if the event will be good enough.
However, IxDA is based on local groups. IxDA-Lansing, for instance, tends to draw people from the Lansing area and nearby areas like Owosso and Flint. IxDA-Grand Rapids will likewise draw people from that area.
MichiCHI is similar in geographic reach to MI UPA.
Because of the geographic constraints, having frequent meetings is easier for IxDA local groups because attendees simply don’t have to drive that far. So, IxDA groups could meet monthly with greater ease, and they would be more relaxed.
However, because people would need to drive further to attend events by the statewide organizations, they could do better to meet perhaps quarterly or even less, leaving the more frequent get-togethers to the IxDA local groups. The expectation is that these less frequent events would be a bit more polished—more of an event than a meet up.
Factor: Approach to UX
What I mean by this phrase is whether the UX focus is more academic (MichiCHI), more focused on usability work (MI UPA), or more focused on interaction design (IxDA). Of course, because we’re all in the same general field, this breakdown should be taken with a pretty heavy grain of salt. But while we tend to operate as generalists in part, I personally appreciate opportunities in each area, so I think there is value in this distinction.
Coordinating events by these various groups
So, given these thoughts, here’s a proposal.
1. We embrace the IxDA local groups
Perhaps we could even create more. How about an IxDA-Detroit? IxDA-Marquette? IxDA-Houghton? (Trying to represent the U.P.) These IxDA groups would sate our appetite to meet frequently for networking, idea sharing, and teaching each other how we can do our work better. In the meantime, MI UPA and MichiCHI purposely slow down the pace and encourage participation in the more frequent IxDA events.
2. we help the state associations with less frequent, more formal events
These frequent IxDA groups can help generate the presentations that could then be shared state-wide at larger events sponsored by MI UPA or MichiCHI. The coordinators of each IxDA group could stay in touch with the events committees of MI UPA and MichiCHi and recommend excellent presentations. And these IxDA groups would help promote and recruit volunteers for the larger events put on by MI UPA and MichiCHI. These organizations are already putting on some awesome events like the annual Internet User Experience conference. Let’s pitch in and help them be even more awesome.
And how to coordinate between MI UPA and MichiCHI?
Beats me. Perhaps some of you have ideas?
We have a really great group of practitioners in Michigan, and we’re lucky to have these organizations actively promoting our field. With a little coordination for each group in light of the others, I think we can tune our professional organizations to work even better together.
Do you do UX work in Michigan? What are your thoughts?
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?
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
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?
I got the idea for the sandwich from an article on LiveStrong.com and I decided to track down a tomato soup recipe to make something of my abundant backyard tomato plant. No kidding, it was the best tomato soup I’ve ever had in my life.
This past weekend Lila, Eva and I returned home from a week-long vacation to the Keewenaw Peninsula in the Upper Peninsula of Michigan. I grew up there, and we caught up with relatives while there. Here are some photos from our trip.
We took a leisurely drive up and spent a morning site-seeing in Taqhuamenon Falls State Park. If you visit the park, the brew pub at the upper falls serves some tasty grub!
An evening at Abigail’s parents’ beach house near Keewenaw Bay
We picked up pizzas and root beer one evening and headed to Abigail’s family’s beach house on Lake Superior. Abigail is my brother Peter’s girlfriend. We had a stone skipping contest, my brothers disappeared in kayaks for a while, and we roasted marshmallows as the sun set.
White City lighthouse and beach at Jacobsville
After a nearly fruitless evening looking for thimbleberries, we headed to the beach at Jacobsville. One of my young cousins here took a weather-cleaned bone as a souvenir from the remains of a bald eagle’s meal out on the walk to the lighthouse.
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.
There’s a trick to getting small-caps to work on the web, and it’s counter-intuitive.
Let’s say you had an abbreviation, like CSS, that you wanted to put into small-caps, say with a little extra tracking. You might think you could use the CSS property font-variant: small-caps, and you’d be good to go. Not so.
Here’s why. Because for small-caps to work, you need to start with lowercase letters.
However, when you’re simply typing your thoughts out before you’ve decided on small-caps for abbreviations, acronyms, etc., you probably typed those abbreviations in uppercase.