• Work with what you have.
• If you have to re-factor, confer with at least two others on the team
• Don’t break what already works unless everyone on the
• Modify for re-use in small chunks.
• Always question mock-ups created in MS Paint. These are suggestions, not things to replicate exactly.
• Ask yourself constantly if there is an easier way.
• Talk about your challenges, there is always an easier way

These are important questions because underlying each is the notion that learning, growth, and right action is taking place¹. Statistics give us a way to understand what we see and to set expectations in an empirical way, based on experience.

Science, numbers, experiments, these things yield data that allow for descriptive and inferential statistics. These statistics help us assess situations. They help give us a perspective that we might not have had otherwise.

Usability involves finding perspectives that inform design. Because usability is about EXPERIENCE and experience is about perspective. Everybody has a unique perspective because their experience is unique. And experience is subjective.

Which brings us to co-creation. The idea of co-creation is a mindset associated with looking at things from a different perspective. A perspective where everybody wins. Everybody has increased value for having been engaged. It’s about people being on the same page. It’s about being truthful.

Studying the numbers will help track trends as things change. Understanding numbers and making predictions require methods of statistical analysis.

Because something will change. It always does.

The Nimble Way observes the interconnectedness of things and reacts to engagement seeking optimal outcomes for all involved. Finding the middle way.

1. Right action…as viewed from the Noble Eightfold Path perspective…

What you build at first doesn’t have to be great. It doesn’t have to have a fancy interface or complete screens. Under the hood it just needs to work. Start simple. If you build something simple at first, you’ll be more nimble later on.

It is important that you have something working as early as possible and that you complete the loop. Most likely the project is to build or program some functionality that has some sort of start and finish. For example: create user, read user, update user, delete user. Understand the life cycle of what you’re doing. Identify it at the beginning of every project you start. It’s there and it’s critical.

Then write it down where others can see it and edit it. Because others on the project, probably yourself, will ask it many times. More important is how you’ll use it to stay focused.  It’s a shield, cattle prod, a shepherd’s hook, to guide us away from the dangerous scope creep cliffs¹². Writing down the critical path of your project is like putting a stake in the ground. You can point to it and say, “we must stay close to this.”

The following must be asked and understood by those designing, building, and supporting a product. Every person working on a project, trying to understand the details and scope of a project, inevitably makes decisions based on insufficient or incorrect information. Document collaboratively the answers to these questions and the result will be a more nimble solution in less time. Someone on the project will need to know the answer to at least one of these questions.³

• How will this be used?
• What components will we use to make it work?
• How will the new and existing components perform together?
• Are we using the most appropriate technology and design?
• How will we release this for testing and use?

Whatever you build shouldn’t break what already works. The less that has to be tested the better. The less stuff you interfere with the better. Implement new functionality in a way that doesn’t break what already has been tested and released. Being nimble means knowing how to avoid sticky and slippery areas.

1. Flashback: Catcher in the Rye.
2. I used to be very, very good at this. I first heard this term from my manager, urging me to stay focused on what needed to be done.
3. Rainwater, J. Hank. (2002), Herding Cats: A Primer for Programmers Who Lead Programmers. Apress. Page 109.

For a business whose product is ethereal in nature and whose usefulness depends on human interaction and the flow of information, there is a constant challenge of deciding what to do next. What design, bug fix, or new feature will ignite and keep the interest of your current and future customers?

In some development organizations, a development leader’s job is not to decide what new design or feature will bring in the money. Their job is to build whatever upper management says. This means being able quickly understand what is needed, how it relates to what already exists, and the ability to quickly assess and devise solutions to the problems of implementation. The sooner something is released the better. Sales and marketing count on it.

New information, the world economy, and a zillion other things can cause priority to change, forcing a shift in attention from one thing to another. Oftentimes customer need or competitive market forces result in new projects that quickly become priority, jostling for position with existing high priority projects.

There are many types of development methodologies out there promising high quality, low cost, and short turnaround times. They typically fall into one of two camps; waterfall or iterative. Waterfall methodologies break projects down into distinct stages and roles while iterative methodologies focus on the deliverable itself with one team seeing the project to completion. There are advantages and disadvantages to both¹.

To survive in any development organization, a nimble approach is needed. When you are told to deliver something and you have a small team of people to do it, an iterative approach seems reasonable. However, not all small teams are tightly knit and cohesive just because they’re a small team. You might also have to work with other small teams from time to time. Unless there is sufficient communication, planning, discussion, and collaboration during a project, the chances of it being high quality, quick to build, and with low maintenance, decreases.

The Nimble Development Methodology is a hybrid of the waterfall and iterative methodologies. Small development teams work together from beginning to end and focus on building and delivering something functional by discussing, designing, defining, and documenting the project collaboratively throughout the development process. The key to nimble development is the focus on project components in order of their criticality.  This encourages the delivery of something useful, though sometimes minimally, in the  shortest amount of time. By documenting just the right amount during development, when attention and effort is shifted to something else, enough detail is left to make it easy to pick up where it was left off.

Nimble development is all about quickly assessing, understanding, and addressing the most critical aspects of a project in order of importance. It then becomes a matter of developing and releasing in that order. This might mean working on the hardest part of something first, but this approach increases the odds of delivering something useful in the shortest amount of time. It also allows for quickly shifting gears toward or away from new or existing projects.

Using the nimble approach, documentation and requirements are created, maintained, and adjusted every step of the way. Using a wiki or other collaborative document application, project requirements, specifications, and notes such as future concerns, ideas, deployment needs, and system configuration notes, are written in concert with development by the architect, developers, analysts, and managers working on the project.

1. See here for a pretty well written comparison of the two methodologies.

And it’s kind of a trick question. Of course users know what they want, don’t want. It’s silly to think they don’t. What users don’t know is what they don’t know: functions and features they don’t use or don’t notice. Who is in a position to find that middle ground of innovation blending how it’s used with what is possible to discover ways to improve quality of experience, usability, and most importantly, usefulness?

HCI to the Rescue
That is where human-computer interaction specialists like Usability Experience Designers and Information Architects are needed. They are trained to recognize what users want and to understand the bigger picture of functionality. They do this by listening, watching, and studying what is said and done. It is the process of gathering, studying, sifting, and sorting what users say they want that leads to understanding not just what users want, but what they NEED.

In human-computer interaction studies, we are taught to truly understand what users want is to listen to what they think they want. Only then can we step back, study, and recognize needs beneath the wants.

We are all users
Any person that uses an application is going to react to it differently to it and will form their own opinion about what makes sense. Usability experience designers and information architects are taught to pay attention to what people want, to watch what they do, and most importantly, to think about what makes sense devoid of associated biases.

Of course you’re the best person to ask about what you think of using an application. If you’re a user like me, you’d be happy to tell a developer what they could do different. And I’d listen.

Subversion an engine upon which Trac draws, but it has equal power in other areas.

It’s Wiki for example. Or the RSS feed provided by the timeline…which means filthy integration potential for IDE plugins for which a number have already established footholds for Eclipse and Visual Studio.

Human connection and sense of belonging power the interest.
Web 2.0 finds root in the human interest to communicate and share experience. Advances in technology allow us to connect to the Internet and computers in more and more ways. We connect and interact, weaving information sharing into our lives. Not just because it’s increasingly easy.

Developers on the backs of giants: AJAX, DHTML, CSS, HTML, XML
With the widespread realization that JavaScript has server and DOM access at the same time, innovations in web applications are like comparing telephone to telegraph.

User experience getting deserved attention.
Because of these innovations, adherence to standards, and in part, the open source movement, user experience is getting deserved attention because developers don’t have to start from scratch. With so many competitors, user experience and content become the discriminator and strategic advantage for securing attention and interest online. These same innovations provide developers new ways to observe and improve the human-computer interaction.

We are learning from each other.
As data is gathered and studied about how people interact with others online, patterns and behavior similar to communities and social systems are finding ground where there isn’t one. As people with similar interests and information needs discover and invent ways to share perspective, opinion, and thought, technology is there recording it all. Everything shared online, explicity or incidentally, becomes part of a vast miscellaneous collection of data ready to be searched, categorized, tagged, and studied in nearly infinite ways.

Look beyond the social ramifications of Web 2.0 and you see a pattern of  potential. Focused and goal driven organizations should be jumping at opportunities to understand and tap Web 2.0 principles of collaboration, sense of community, and involvement. These are matters of behavior people!

Who doesn’t want a strategic advantage? That advantage can be gained by recognizing the importance of online involvement, investment, and sense of self cultivated through interest and curiosity.

In the digital vastness geographically distributed across millions of computers, saving and sharing of data in parallel  at an incomprehensible speed¹ is happening right now. Massive amounts of data that include pictures of your kids or you and friends partying at a beach house.

So many ways to connect and places to visit, it’s easier these days to make connecting and visiting part of your daily routine. How much time you have may vary, but we’re connecting when we can. And it’s often. Maybe you’re checking if a friend is back from Florida or how that one event went that you couldn’t attend. Maybe what your friends are doing right now.

For those not sleeping on the streets of the Internet, putting oneself out there is scary. You want to feel confident that bits specific to you aren’t free to anybody. Maybe you feel secure using a mail client that downloads mail from server to your local computer.

Portals are a significant next step. Web applications requiring you to identify yourself are suddenly available and offer access to information and resources unheard of. Many of them give you control of a private, personal, secure, warm and crackling bit of digital fireplace coziness; your online living room or office. A digital presence. Accessible from anywhere and through anything that can talk to the tubes.

Then along come awesome phones and technology boundary jumpers like Facebook, Twitter, Yelp, Gmail, Wikis. These applications let you tap into the running dialogues that make up the online singularity. Low barrier of access and vast amounts of contextually appropriate information. Relevant and useful to you, when you want it. Huge potential to know a lot about a lot that’s going on.

But for many, this data isn’t the same as the data you keep in email or in files on your computer. Data having to do with finances, love letters, payroll reports for that little business on the side. That isn’t data you want to share with people so much. Well…not usually, but sometimes maybe.

A single point of failure is so last millennium. Like when it’s time to do taxes, or pay bills, or manage a soccer team or golf league. Or when the power goes out or a hard drive fails. Or when your USB drive takes a crippling EMP pulse from an advanced alien ship that passed you on the way to work.

Maybe having a small apartment closer to the city. Something simple, online, that gives me a key, running water, heat, and electricity. A secure and accessible area in the Cloud² where I can set up camp. Maybe build a city or an empire.

1. This is what brains do, by the way. How consciousness emerges, well…that’s another thing entirely. I have no idea.
2. FTR – The Cloud: another way to refer to the Internet. See here for a much better description or search on it.

So first, who are the people that blog? We can assume that the people that blog are those that have access to a reliable (and usually high-speed) Internet connection. They also have a certain understanding of computers, surfing, and can read. Like you.² We can also assume that for the most part, they have a reason for blogging because let’s face it; it’s an intentional act. You won’t hear, “Oops, I just blogged about blogging again…my bad folks…my bad. I’ll be more careful.”

The people that blog are not people. They are persons. Blogging is an individual endeavor and each blogger is likely to offer you a list of ever changing (but with a fair share of persistent) reasons. Let’s consider the how Nardi et. al look at this.³

To let other people know what’s going on. Maybe you’re writing about the wine industry in Northern Michigan, maybe your writing about your experience in graduate school, maybe you write about your business as an accountant.

To seek an opinion or feedback. Maybe you blog about consumer devices, new technology, or politics. There are many areas of interest that actively seek to get others involved in the dialogue. Discussions boards meet this need better but blogs are a good place to light the fire.

To think by writing. There are many blogs by people that use the opportunity of writing to sharpen their thoughts. Writing is a serial process and requires bringing together, into these short sentences, coherent thoughts that others can understand. Read what you write if you’re doing this as that is part of the thinking process too.

Sometimes to release emotional tension. Sometimes venting can be good. Dangerous to the feelings of others at times, but some amount of healthy and intelligent venting can act as a release valve to keep from building up too much internal pressure.

And sometimes it is for all these reasons at the same time. Writing and reading what others write is one most effective ways to share one’s thoughts. And if you think about it, sharing thoughts, however you do it, is fundamental to society.

Image: This was originally used in my blog on moonlighting as a student but it seemed fitting to this entry. This is a picture of my step-mother reading a blog post of mine where I was demonstrating “focus + context” on my phone using my blog as the site.

1. And how can you know who is reading your blogs? Like, what information is available? We’ll consider that in the technology part when I cover logging and analysis.
2. After all, you’re hear reading my blog.
3. Nardi, B.A., Schiano, D.J., & Gumbrecht, M. (2004) Blogging as a social activity, or would you let 900 million people read your diary? In Proceedings of CHI 2004. New York: ACM. Pp. 222-231.