Like I mentioned in my previous post, one of the first tasks in user experience design is to concretely understand the goals of the project stakeholders, possibly helping them flesh out thoughts and abstract ideas in the process. Stakeholder interviews, as described by Shawn Crowley at Atomic Object, are intended to help bring those thoughts to the surface and, through discussion, document a set of goals and motivations. The system he described involves a pair of interviewers and a single stakeholder interviewee: one interviewer guides the discussion using a mix of open- and closed-ended questions while the other takes notes.

The questions should try to draw out not only qualitative descriptions of goals, but also quantitative when possible (e.g., Market saturation percentage targets, net income). Some questions we discussed include:

• What is success? Failure?
• Who are you doing this for?
• What are your constraints (time, money, etc.)?
• What is your vision for this product?
• Tell me the future

For the note taker, a set of 3×5 cards should work well for documenting statements the stakeholder makes. The notes must be factual, not the note taker’s opinion. After the interview, both of the interviewers should review the set of notes to make sure they are factual — grounded in reality. Any statements that are tainted by interviewer opinion should be discarded or distilled down to the factual information. After the interview, review the notes with the stakeholder using whatever method you deem appropriate (I’ll probably send a follow-up e-mail, since I tend to do that after meetings anyway). If you must make assumptions, be absolutely sure you check those assumptions with the necessary stakeholders or you risk driving the project off course from the very beginning.

Now that you have one set of information, repeat the process with others involved in the project. Stakeholders can take a variety of roles, so be sure that variety is reflected in your pool of people to interview. Previous interviews are likely to identify new people who should be interviewed. I’ll be likely to include people from business leadership, marketing, and other subject matter experts in my interviews to be sure we are getting the whole picture and describing goals clearly.

As Shawn and I discussed, the value of these interviews lies in the focus on fact. We can use the information we gather to reflect the business goals, metrics, and target audience back to the stakeholders as a framework for discussion. This becomes a single point to align the stakeholders, developers, designers, and others involved in the project toward the same set of goals and will be a valuable tool to guide decisions down the road.

In theory, that is. We’ll see how it goes.

There is an awful lot of documentation on the internet about user experience design. I’ve read through a bit of it, and through reading I came to understand the basic gist of things like stories, personas, and wireframes. Until yesterday, though, I still felt like I wasn’t getting the big picture — how do all of these things fit together and eventually lead to an informed project plan? Thanks to a great Thursday afternoon discussion with Shawn Crowley over at Atomic Object, I’m starting to see how I can apply the process of UX design to my project. Instead of sharing particular methods first, I’d like to talk about general application of the process to my project and how I envision it will provide value for me, my fellow developers and designers, and the project stakeholders.

Shawn did a really great job of walking me through the process Atomic Object is employing in user experience design, and that has helped form in my mind an idea of what the process is intended to achieve — the big picture that was missing from online materials. Apart from any concrete deliverables, their aim is to:

1. Identify stakeholder goals & motivations
2. Identify & understand target audiences
3. Identify activities involved in achieving stakeholder & user goals
4. Assemble a high-level release plan for estimation & evaluation
5. Add detail to tasks for the first release to support development planning
6. Execute development & other design activities to implement release plan

Concrete deliverables from the process will relate to one or more of the abstract goals above. Each step builds on the previous, introducing new information and keeping the process grounded in facts.

I’m going to start at step one by asking myself a simple question, “How do I identify stakeholder goals and motivations?” One of the methods Shawn and I talked about was a pair interview with a stakeholder: one person asks questions while the other person writes down facts to be reviewed later. But, I already have answers to a lot of the questions I’d ask and I don’t want to waste someone’s time asking them questions I already know the answers to. Instead, I’ll probably start by writing down facts I already know and review them with the stakeholder in a brief conversation. Not that I wouldn’t like to interview them, but it wouldn’t add a lot of value for either of us at this point. I’ll tackle each goal in a similar way, identifying methods and deliverables that have value to me and to my stakeholders, up to the point where I’ve achieved my goal of providing an actionable, loosely estimated release plan.

The process of user experience design is not one for robots. The decision to include or exclude specific techniques or artifacts is entirely up to you, and should be based on the value that they will provide you, your stakeholders, or others involved in your process. Ask yourself and your stakeholders how a particular method or deliverable helps you achieve your goals before blindly writing a detailed process flow or creating a wonderful functioning prototype. For me and my stakeholders, things like high-level stories, reasonable personas derived from past user labs, wireframes (rough, sketchy mockups), and context scenarios are going to be of primary importance because they are useful in communicating our vision. Other artifacts, like content inventories and prototypes, aren’t as valuable to us at this point because we’re still trying to determine the value of our ideas.

At each step I’ll be using the results of the previous steps to inform decisions about prioritization, keep product features and functions on target, and squash disagreements not based on facts.  I’m really eager to see where this leads because it appears it will help answer questions I’ve been asking myself and my teammates about communicating project ideas and keeping a cohesive vision across functional teams.

Again, I have to thank Shawn Crowley and Atomic Object for giving me the opportunity to learn from their experience. I’m looking forward to continued conversations as I begin to put user experience design principles into practice, and I’ll do my best to keep sharing what I learn.

• Drawing graphs with Perl & Cairo (notes from GRPM meeting months ago… sorry for the delay)
• Fun with mad libs in Perl
• Discussion on testing with Perl — Test::MockObject in particular
• System testing with Selenium & Perl
• BarCamp Grand Rapids, GRPM, and other user groups
• And plenty more Perl!

First, let me define what I mean by the phrase old and crufty.  When was the last time you cleaned out a communal refridgerator at work, church, or even at home?  What did you find?  Chances are you threw out anything that was obviously bad or wasn’t in a reusable container, but what about the questionable items?  You left them in there because they might belong to someone else, and they might still use them.  Even if you wouldn’t, they might.  So they didn’t get cleaned up.  That is what I call cruft.

Software developers don’t like cruft.  In our own code, we have the ability to see what is used and unused and clean vigorously.  It feels good to finish a rewrite or update to a system knowing that everything is nice and tight —  shiny code.  Or at least my perfectionist tendencies make me feel that way.  So, when I see comments like this on the Perl 5 Porters mailing list, it makes me cringe:

But I’d be scared of making it in any stable release as I would be surprise if someone somewhere isn’t matching on it, and ignoring the current term.

The change being discussed isn’t necessarily even one I would be in favor of, but it is a classic example of the kind of talk that leads into the perception of a language being full of cruft that developers don’t like.  I can understand how, through reading this type of comment, a person could come to see Perl as a language that is dying, not advancing, because the community is too afraid to make changes that would improve the language.

Now for some positivity: I think this perception can be changed, partly through the addition of quantitative analysis.  For example, if we take CPAN to be a (non-random, obviously) sample of all Perl code, then we can check to see if any module on CPAN checks the actual value of a warning someone requested a change to.  There are other Perl-based open source projects that can be grepped (or Ack-ed) through to quantify the potential impact of a change.  Instead of stating, “someone, somewhere might use <blather> for <unintended_use>”, try to add to it, “… but there were no modules on CPAN that did, and neither do open sourc projects A, B, and C.”  Perhaps we could even put together a set of projects and a tool to check outside of CPAN to make it easier to judge the impact of a proposed change.

Thoughts, anyone?

Unused

It is all too common to find unused variables, subroutines, or unnecessary libraries included in a program. Often they are remnants of a shoddy refactoring effort, or the result of a developer who is outside their comfort zone with the language and tools being used. This excess code can confuse unwary maintainers or, in the worst cases, cause errant behavior in the software. Clean up anything that is not necessary in your own code, and encourage others to do the same. If you are unsure whether removing a variable or library will break your code, test your suspicion instead of letting your uncertainty remain. 

Duplication & Stagnation

When confronting someone with a refactoring need, how often have you heard the excuse, “But I’m afraid I’ll break something.”? The fear of refactoring can lead to duplication of code, lingering problems, and general stagnation of the code base. As Andy Lester mentions in his technical debt presentations, even the feeling that code is broken affects how we deal with it (the broken window effect). We hopefully learn more about our craft every day, and refactoring is a valuable way to apply new knowledge and best practices to our work. 

Probably the best way to give confidence in refactoring is to have a solid suite of tests covering the affected code. It is very reassuring to see tests pass before and after large changes. Spending time to develop a deeper understanding of a program’s function also lends a degree of confidence — I suggest spending that time writing or improving the test suite.

Why does it work?

As software developers, we ought to be able to explain how and why our software functions, not just declare that it passes the tests. A lack of understanding can lead to unexpected behavior in untested situations and nightmares for anyone left to maintain the code. If the person who wrote it can’t explain how it works, what hope does anyone else have?

Pair programming requires talking through code as it is written, and that helps understanding a lot. If you find yourself alone, talk it through yourself or find someone to explain it to later (as part of a code review process, perhaps). Ask questions of your fellow developers when you don’t understand what they’ve written, and be prepared to question your assumptions when things don’t work how you thought they should.

My initial search for the download page was performed in IE8 Beta2’s Live Search bar (take that, Microsoft!) and I didn’t get the results I expected — surprise! Instead of a prominent download link, I was presented with several news stories and a link to Google’s little comic commentary about Chrome (which is a good read, by the way). So, I just went directly to Google and searched there, and of course they had the download link in the Sponsored Links sidebar as well as the first position below news results. I tried the search for “google chrome” also at Yahoo and AltaVista, just for kicks, and noted that the download link was near the middle of the first page of results. Odd, then, that it doesn’t appear in Microsoft’s Live Search results at all, don’t you think?

Anyway, I installed it and poked around the web a bit, paying special attention to sites like GMail and agentzh’s blog that are heavy on the Javascript. Overall, it worked well enough. I didn’t notice any drastic difference between my typical Safari 3.1 and Chrome, though it was quite snappy in GMail. Nice job, Google.

Of course, we all realize that in the end Google’s release of Chrome is a self-serving action. Better browser performance means they can push their apps harder, and improved perception of security and stability might make people more apt to use online spreadsheet and word processing tools. I applaud their efforts just the same, and I think we all hope this pushes Microsoft and Mozilla toward further innovation.

These are my unfinished, unpolished thoughts, bound to be revised and rethought.  I publish them in the hope that they might spark your imagination and make you think, if only a little.

Sparks & motivation

This talk came about because a few things I’ve read and heard recently (particularly from Andy Hunt — see the link at the end) have resonated strongly with my own feelings that the software development community is, perhaps unknowingly, ignoring a few core skills. We tend to focus so much energy on creating, teaching, and learning new tools and methods that I think we may be losing focus on the other things that make us good software developers, namely our problem solving and design skills.

It’s not that tools are a bad thing — they are very important. But, does using Photoshop make me a designer? Does owning a wrench make you a plumber? So, then, neither does opening up Vi or starting up Eclipse really make anyone a software developer.

As Andy Hunt said in Pragmatic Podcasts: Andy Hunt on Pragmatic Wetware, “Software is developed in your head, and in the heads of your team members.”

Problem solving

I had a particularly interesting interview a short while ago. The first question I was asked, after introductions and obligatory handshakes, was to show how many snowflakes had fallen on Earth since the beginning of time. A dry-erase board and marker were the tools provided. At first their request sounded a bit odd, and it was a bit intimidating, but in retrospect it makes plenty of sense. A lot of what we do as software developers is break large, impossible-sounding problems down into smaller bits that are easier to understand and solve. Reassemble those pieces correctly and you’ll also solve the larger problem.

Tools or preferred development methodologies might have some impact on how you approach the task, but I think we’d find more similarities than differences. Consider that nearly all programming languages provide facilities for managing these smaller pieces. Whether they’re subroutines, functions, macros, or our favorites from OO (classes, methods, etc.), their purpose is to help you break things down into manageable chunks. Modern IDEs make it easy to manage large groups of files and dependencies.

Applied

It takes time to load up the context of a problem into your brain. And it only takes one disruption of the wrong type to blow it. To help the design process, I tend to:

• Talk through it with someone else, possibly away from our desks to avoid interruption.
• Put on headphones if I’m working alone in a distracting environment.
• Take short breaks to let ideas settle and when you hit particularly troublesome parts.
• Keep it simple. Resist the temptation to make things more complicated than they really need to be. Agile’s YAGNI concept falls under this idea, but is only one example.

Also, any code you don’t have to write yourself decreases the amount of information you have to load into your brain. Use libraries from CPAN, Ruby Forge, or wherever you prefer that have already been written and tested.

Design

Software developers actually do a lot of design work — we follow the same process as nearly any other designer:

• Analyze the problem with the customer
• Take the intended audience into account
• Create a solution

So, there is a lot of creativity involved. This is one big reason why I really enjoy being a software developer.

One interesting thing I’ve noticed is that we software developers don’t really test the usability of our code. I would love to see someone put together a serious usability test of a few different languages or libraries — I think we would learn a lot about ourselves and put some concrete evidence behind coding standards and best practices.

Applied

Differences of opinion are okay. In fact, they’re a major contributor to success in any design task. Agile development encourages this through pair programming.

A lot of the time, we and our fellow team members are the most significant users of the classes and modules we write. At the very least, it’s going to be another developer using it. Be kind to yourself and the other users — put some serious thought into how users will interact with your code. Maybe even do usability testing.

For more…

Pragmatic Thinking and Learning by Andy Hunt

Gain a new perspective

Different people approach problems in design and technology from different angles. That’s a great part of being human — we’re all different. BarCamp provides an opportunity to share your approach and listen to the thoughts of other people. So pay attention. Paradigm shifts included free of charge.

Be a part of the community

Design and technology play a major role in companies across West Michigan, but how often do you really interact with these people outside your own company? We often share goals, challenges, and interests, and we all have a lot to share and a lot to learn. In short, forming community makes us all better at what we do. This is one of the times it’s good to be “one of those people.”

Get free stuff

There will be food, for sure, but rumor has it there may be other extras for the participants. Who doesn’t like free?

Practice, practice, practice communication

The best way to perfect something is to do it over and over again. And, truth is, very few of us have perfected the art of communicating with our fellow humans (especially some of us tech geeks…). So, come out and give a talk — it doesn’t have to be long. Share something you’ve been working on, or something you’ve observed about design and human behavior. We appreciate all contributions.

Meet people who appreciate your humor

It’s not everyone who understands how to turn a <div> tag into the perfect sippy cup for a toddler: 

div {
    overflow: hidden; /* Keep messes in check */
    padding: 1em; /* Don't hurt anyone */
    vertical-align: baseline; /* Keep it on the table */
}

Hope to see you there!

BarCamp Grand Rapids

BarCamp Grand Rapids is returning to Calvin College on August 15 and 16, 2008 for another two days of informative, informal, inverted conference. If past years are any indication, there will be plenty of food, tons of geeked-out conversation, and piles of new information that no one should miss. So, put it on your calendar, and we’ll see you there!

I am getting tired of reading blatently wrong, un-researched, and yet boldly-declared information posted on the web. Not postings on puny personal blogs (like mine), those I can forgive. Instead, I’ve been seeing news items and statements on supposedly trustworthy sites that just don’t get the facts straight. This has been particularly and most recently true with the slew of press releases covering the release of Perl 5.10.

For example, take this article on LinuxDevices.com. Like several other press releases, they claim:

Just in time for Christmas, there’s a new version of perl, the first in over five years.

Perl 5.10 is not the first release in 5 years — it is the first feature release in that time. That is a big difference. There have been many stable releases since 5.8.0 that fixed bugs and improved Perl’s performance and stability, which paints an entirely different picture from what the article actually says. Their news item makes it sound as though Perl is an unsupported and inactive language, which is entirely untrue.

Also, the paragraphs comparing Perl to Python, Ruby, and PHP is laughable — and I’ve seen this exact text on several sites (eweek.com, for example). Yes, there are a lot more people using those languages today, and they are growing, but Perl still holds a formidable share of the dynamic language job market and that doesn’t appear to be changing rapidly. Don’t claim that Perl is a dying language unless you can show evidence.

Please check your facts before you post! It’s better to be correct than first.

(And FYI: Ruby is not a language “specially-made for use on the Web”.)