Over a million developers have joined DZone.

The Beginning of Personalization

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

The age of highly personal computing is emerging. Follow any major technology news source and you will hear about semantics, relevance, and intelligent agents almost daily. The emergence of tremendous compute resources is making it possible for us to finally start tackling this computationally intense problem. Entire new disciplines have emerged to model our world and how we behave in it. The accuracy of these models constantly improve and our ability to apply those models to our software interactions are increasing dramatically. There is one modeling technique however that has always existed, but as software engineers we tend to do poorly.

How do we usually refer to those that use our software? Users? Customers? Maybe their role? Consumer, buyer, supplier, merchant, administrator? Those are all accurate and reasonable monikers but they fail to state, with impact, who we really build our software for. We build our software for people. People USE our software but to call them USERS, has a dehumanizing affect. And I believe that the current state of usability is largely tied to this impersonal nomenclature. It's a lot harder to generate an experience that is mediocre if you put yourself in the context of the person using it.

How do you write your user stories? Are they an impersonal collection of tasks?

  The user moves files from the source folder to the destination folder. The contents of each file should be clear.

Or are they directly tied to outcomes and stated in terms of a person.

Jane is facing the prospect of organizing a large volume of content. The job is tedious at best and mistakes can be easily made unless the purpose of each file is clear. Jane needs to complete the task of organizing content quickly as this is only one of many things she must accomplish today.

Both stories provide the same information about what needs to be built. But the second gives insight into why it must be built, what the person you are building it for is facing, and why it is important to make it easy and efficient. Jane is a busy person and doesn't deserve to be punished with a suboptimal experience for organizing content. I mean, what did Jane ever do to you?

The best part is that this is a simple thing to do. Simply change your vocabulary. Stop talking about features for customers and start talking about outcomes for people. It doesn't require a change in any process, any new tools, or any new skills. It is just a matter of changing the way you express the changes to the product you already plan to make.

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.


Published at DZone with permission of Dan Pritchett, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}