All of Us as Accidental Systems Designers
Michael Calore’s Epicenter post “Gmail’s New ‘Add Location’ Feature Is Too Honest“ talks about how you can now agree to have GMail automatically add a location line to your emails. I suppose mine would say “Santa Clara, CA” right now. Calore says he won’t be opting in to this feature until it allows him to lie.
He provides an clear discussion of the issues of automatic location awareness — nice to share where you are:
…location data adds value to just about every web service. It increases the relevancy of search results, makes online mapping more useful by a factor of ten, and, when combined with a good social network site, it makes meeting up with friends easier.
But he also points out the complexities: Sometimes it’s wrong based on your network setup (his hardwired connection showed him in NY – the company’s HQ – while he was actually in San Francisco) …and sometimes you don’t want people to know where you are:
The obvious argument is centered around privacy. Sometimes it’s trivial, like when you send a note to your boss saying you’re sick, only to have your e-mail signature rat you out by announcing that you’re sitting behind home plate at the ballpark. More seriously, there’s e-stalking and the open invitation to unwanted guests. Also, letting everyone know where you are all the time is just creepy. As a society, we’re not ready for that yet.
He then goes into the options you have for managing the process — thus, all of us as systems designers. You could physically retype the line with the location. You could (not me) create an application that overwrites the location. I suppose you could also turn it on and off, but you’d need to do it randomly or people would know you are trying to hide your location for cause.
More and more we have to take on the role of “accidental” systems designers, and I don’t believe we are ready for it. As Calore says, don’t opt in unless you understand the consequences. Many people on are the Internet. Few understand the architecture. Multiple examples in the last month of kids not understanding how much monitoring goes on, for good and for bad, and their not knowing how to control it even when they can. Cloud computing complicates the picture of where your data is and how to back it up, and who has rights to it.
Mark Fuller, Greg Northcraft, and I wrote a chapter called “Borgs in the Org: Organizational Decision Making and Technology.” There we say,
It seems critical to help users understand that availability and implementation of technology is just the beginning of effective use.
We argue that we need to be flexible with the adaptive structures (looking for new better uses); we need to grasp organizational realities (e.g., is there a guest network at your client’s office, or not); we must understand that systems integration is a life skill; and we must know when to stop.
Danielle Camardo, Nicole Yee, and I are working on a project related to how faculty teach in this environment, so these issues are on top of mind for us. We would appreciate comments on how normal people handle their roles as systems designers/integrators. Most of us learn by doing. But is that going to work in the long run given the complexities of this environment?
9 Responses
February 13th, 2009 at 12:08 pm
I would say yes to the ‘learning by doing’ question. But the decision to participate and learn should be made like any other–with an understanding of the risks and rewards. If one stands to gain (either personally or from a business perspective) from becoming more involved, and that potential gain outweighs the potential risks, then jump in with both feet! Otherwise, not so sure…
February 15th, 2009 at 11:17 am
What I’m seeing is that the complexities of the risks and rewards are going beyond what non-tech-focused people have reasonable access too. I’m being asked to do the analysis for some groups, but I also wonder if we shouldn’t be teaching some form of systems design approach just like we teach the 3 Rs?
March 22nd, 2009 at 1:16 pm
[...] who are likely to try new technology tools at work. I’m still playing with the ideas of All of Us as Accidental Systems Designers and trying to understand why some people take to this role easily, and others do [...]
March 26th, 2009 at 10:24 am
[...] issues identify that a key skill we need in our roles of accidental systems designers is the ability to understand and manage privacy and information access. Motahari, Manikopoulos, [...]
March 30th, 2009 at 8:01 pm
[...] going to add DaDT to my list of requirements for All of Us as Systems Designers. Slowly but surely I’m building a list, and this requirement seems critical in modern work [...]
April 22nd, 2009 at 10:49 am
[...] more I think about “All of Us as Accidental System Designers,” the more I wonder about how to teach the skills. Yesterday I spent the afternoon on a [...]
August 9th, 2009 at 10:26 pm
[...] going to make the individual the focus. This is a chance to bring my perspective of “all of us as systems designers” into a formal research setting. My past blog discussions have touched on ideas of owning [...]
October 1st, 2009 at 11:26 am
[...] Given available options, we are all becoming learning system designers (just as we are all becoming systems designers of our work settings in other ways). At the same time, knowledge is becoming more of a currency. Use your knowledge of [...]
February 4th, 2010 at 3:27 pm
[...] All of us must be systems designers to be effective in our current environment. We must make our own choices about how to weave together technology, organization, and people dimensions of our work. I feel that Piazzza is giving my students greater opportunity to make the best design decisions for themselves. Neither the technology or our practices are silver bullets and Piazzza allows us to use the technology to design practice at the class level (how we promote particular uses in class) and at the level of the individual (how individuals choose to interact with the material). We are integrating the technology and the practice. [...]