Printmaking
After doing aerospace research and other wandering around at school, I ended up with a Printmaking degree. The fine arts one, where you cut your own plates, and make one print at a time. But in doing so, you learn a lot about the principles behind press operation, about how inks interact with each other, about how paper works when wet and compressed vs. dry. So, a couple years later when I am doing graphic design for a living -- because art pays poorly -- I am suddenly doing presschecks on the magazine I am art directing. At 2 am I am off at a printing plant in the middle of nowhere, telling the press operators what I think of the output. And very often, annoying them. Because I know just enough that I don't say "aww... it looks funny there..." but instead say that I think they should punch up the magenta three points on channel 7 and 8, and fade it in the two adjacent channels. They argued with me on that one even, but I made them try it. And I was right. Because I knew a little about their business, and a lot about how I wanted the implementation technology to make my design work. This wasn't just historical knowledge that I applied. I also learned more from observing the results, and made my own color matching adjustments. I managed to find a swatch book made on the same press (well, a Komouri Lithrone 20, whereas my stuff was being printed on a Lithrone 40, but close enough) and took notes about how the results varied. I improved my technical knowledge, while never actually being a press operator.Furniture design
In college, as part of the design side of things, I took a couple furniture design classes. I have always thought this was a hugely interesting class, as it taught from several points of view, and essentially has the design/implement philosophy totally baked in. Plus, now I can make furniture. Sure, we had to approach it from the point of view of decoration and aesthetics. And we had ergonomics books, guidelines to follow much like usability practitioners but with pretty much no argument about how people fit into certain shapes; these heuristics were set in stone. But, despite being a studio class in an art & design school, we had to build everything as though it would be mass produced. And that meant much of the sketching started involving materials, fasteners, and processes of assembly. Sound familiar? In this, and industrial design generally, the designers do not then go work in factories and make stuff. But they do work with the manufacturing engineers, process designers and actual factory workers in some cases, to make sure their product can be built, can be built quickly and efficiently, and keeps being made the right way.My Business Card Used to Say Web Developer
Okay, not really. But only because I never saw clients, so didn't have business cards. Yeah, I was one of those generalists. I was a graphic designer, who started getting client requests for websites. I'd made some back in college right when the web appeared, so became a self-taught presentational developer. Most real software developers were too busy lamenting the loss of the Holorith card, and couldn't be bothered with the small clients we worked on, while populating the web with every business in the world, so we had to do it all ourselves. I wrote actual software (poorly). I was a DBA for all intents, designing and implementing data storage, middleware and linkages to get to it and controll it. I wrote presentation code and sliced up Photoshop images (back when it didn't have layers!) to put in my table based layouts.Learn more, practice less
Over time I have gotten out of being anything like a developer. I still build stuff sometimes, for myself. And I include code snippets when I know something will be tricky. I even keep my hand in enough I was able to be the technical editor for a book on developing for Webkit. What happened is that we all became better at our jobs by being more specialized. I became an interaction designer (or often, an interaction design manager). I guided my teams of usability engineers, developers, graphic designers, interaction designers, and so on to do even cooler stuff by making sure they collaborate, and use their more specialized knowledge to contribute to the team better. By continuing to be aware of implementation technologies, I will often write psudocode or algorithms when the team isn't getting the point. I generally use the knowledge I have of the many, many, many systems involved to help make the technical teams talk to each other. Often, this means I can fix problems, small or large, for developers. Or, just use it to make sure a design is implemented. Just the other month, I had to ask three times to truncate by actual space, not character count. Then I just sent over the actual code (markup, one jsp version, two js versions) to implement it. Not only proving it was possible, but giving options; implement however you wish. But do implement it like I specified and stop saying it's impossible. Okay, I like solving these problems, so I'll share two more anecdotes, from different scales and types of systems: I delivered a design document for evaluation to everyone. Most folks love it, we do some tweaks and fix some stuff we missed. But one team is terribly, terribly worried about the data transfer requirements. It was all about doing intelligent things based on what the customer was up to, so we needed to log all this behavioral data whenever they touched the server. So, I sat down with the developers, and in 25 minutes I got them down from their estimated 100 kb of transfer per touchpoint, to... zero. It took a couple steps, but I showed them how you can encode stuff, how we don't need all that data, so can boil it to the basics, and then that we just need a user ID key and time. And then that we already are in contact with the customer so can just do all this on the server side, with no new data transfer. One of my favorite projects ever -- even before this part of the story makes it better -- was a web-initiated SMS tool. Updated a clunky, difficult one, to one so easy it was used millions of times a day, and had no help system, and no complaints to customer care. Great stuff. But a few weeks later development comes back to ask us where the CAPTCHA goes. Well, I start by saying "we're not doing that." And we didn't. We got a few days to look into it, while they lived with evil Eastern European spambots, and discovered that individual Evil Communist Servers were sending 2,000 requests a second. We were fulfilling them. Well, that's easy. No one can type that fast. We blocked the resubmit, invisibly, without error messages to around 10 seconds*. We just removed the economic value of the bots, while not bugging our users (P.S. I have never used a CAPTCHA for any design). These solutions were all about using data, thinking identifying the problem, analyzing the true issues, and using your multi-disciplinary knowledge to find solutions. Speed and common practices won't get you there. Thinking from just one point of view, approaching from one technical point of view, won't get you there.Who does the design?
Which points right at he biggest practical problem I have had with the designer/developer motif: No one actually designs. I mean /really/ designs. Sits down with paper, or whiteboards, or just talks to business owners with a totally open mind about what they want, and does not at all think about data storage or bandwidth. Or even thinks about multiple solutions, and talks to the team. Or considers options they have never heard of, and searches the internet for a few seconds. It's not that they are bad people. I can partly say this because I have fallen into these traps myself, and it's the reason I have these beliefs. I analyzed my results many years ago, saw what I was doing was stupid, and fixed it. The problem is schedule, process, perception and peer pressure. Development is a quick solutions world. One where documentation is increasingly a bad word, and analysis is met with skepticism over the delay it will induce.Software design is design
The best work I have seen comes from not just working with implementation (at every level) but from those development teams who take time to sit as a group with a whiteboard themselves. They do software design. Yup, that's a thing. One of my favorite things that can happen on a project is being, as the UX guy, invited to a software design meeting. Often, these are secret; if not on the dev team you are not aware of it, much less invited. So aside from conducting such design on my own, or with my teams, I have witnessed them as a guest, with no influence over their operation. And they are brilliant. They gather the team, come up with the best technical solution, and decide for each component whether to build, borrow, use a library or explore further. Researching better solutions is a valid course of action. Work gets split up, and is managed a lot better than you'd think, to make sure dependencies are covered and no one steps on toes.Avoiding the heuristic solution
Good software design starts to look a lot, in principle, like what I am talking about as far as good design process. Avoiding the heuristic solution is about designers not designing, and first asking questions. As much as possibly, you divorce yourself from your practice area to get the information needed to do your job in a few more days or weeks. When I work with development processes, I encourage the same of implementation teams. They need to stop, briefly, and understand the problem space and what is being asked for. Then they can approach the solution creation a lot more efficiently.What this all means in the end is that I argue that designers shouldn't code, because the code gets in the way of their focus on design. It also means that developers shouldn't design (UX, UI, Ix design) because it gets in the way of their ability to design and execute software. But the core concept is still true: regardless of your official job role, don't be insulated from all other jobs, but learn about them, and become literate in the skills and techniques of the rest of the team. From sales and marketing through data storage, know about your business and technical domain. Know a little about everything, but don't try to do everything. We had a backlash at the "web designer" and made generalist a bad word for a while. There was a good reason for this. Let's not learn that lesson all over again.
* This is probably still secret sauce, so I'll avoid the various actual numbers we used. We made the value variable, and it took a couple weeks to find the best balance. But again, based on observation and data.
No comments:
Post a Comment