design of my everyday things
Lots of good reading over the past few days, from the four steps to the epiphany to the design of everyday things. Together, the two give me a lot to think about with regards to how I design things, and makes me see the things I have built in the past in a new light.
During my last job, I was responsible for overseeing our tech group in the creation of a productivity/workflow tracking and management system. I found myself in a position of constraint. On one side, the consumers and users of what I was creating wanted to see a very broad range of information in easily digestible form (though they had a hard time agreeing what exactly they wanted and why) and on the other side, I was constrained by the available technology (or, more precisely, constrained into a particular, non-optimized technical solution).
As I look back on that situation, it violated both Steven Blank’s and Don Norman’s theses, at the same time. The majority of our requirement gathering was done on one end of the end consumer (as opposed to user) side of the equation. The technology developed was not, itself, flexible enough to actually allow for changes based on customer feedback, and the constant request for more features was not tamped down. I tried to please everyone by adding in everything. The end result was a piece of software that did some things decently, many things poorly, and that eventually crashed in on its own infrastructure (more of a technical fail of scaling than anything else, but also a result of trying to do too much). When I look at the design of what we built itself, it made sense from a certain perspective, but was very much lacking in terms of convenient and easy interaction for the primary user. Simple things, like a total hours capture (for end of the day book keeping) were absent, and could not be created later without material investment from our tech team. That’s the opposite of agile, and the opposite of functional design. In fact, it is exactly what happens when engineers are given a boatload of features marked “must have” and told to just fit it in.
Though I was at a large company and did not have actual control or decision power over what basic architecture we would use (to maximize extensibility and eventual scaling), and I did what I could to make the design choices as clean as possible, knowing what I know now, I would have charted a very different course through that project. Namely:
1) create an explicit hierarchy of needs for the product based on both user and consumer requirements (which, at its heart, includes a definition of what our market actually was)
a) includes extensive customer feedback sessions based on mockups pre- build (what Blank refers to as demos - without a full working model)
2) design evaluation with the users: actually observe them using the product before making it a requirement, instead of assuming they would learn all the tricks I knew from designing the thing (don’t rely on knowledge in the head)
Granted, this was not a startup situation, but the lessons are still incredibly relevant. We may have still run into trouble based on some of the root choices and abilities that were unavailable, but I think we could have done better. Great lesson.
