Last Wednesday night I headed out to London IA, a social networking event for people working in Information Architecture, User Experience Design and other related fields. I don’t work precisely in this area, but I’d like my work to involve more direct interaction with users. Research on people’s experiences is what I’m trained to do, after all, and I miss it. My job is good and it’s given me a lot of new skills, I’m just hoping to get to a point where I get to use both sides of my brain, as it were.

Anyway, I felt awkward at first socializing with people who are working in those fields as they asked me about what I did. However, when the first speaker, Mags Hanley, began to talk about the skills and tools of a well-rounded IA professional, I began to realize how much that resonated with the work that I do now, though it comes under a different name. Basically my current job has two bits: I report on how the business is doing, and I use a program called Crystal to design reporting tools that other people around the business can run themselves.

Both sides, the web reporting side and the reports design side, involve asking complex questions, designing methods to answer those questions, interacting with users (in this case, other people in the business) to make sure everyone is after the same thing and understands the meaning of the results they’re getting, and testing stuff to make sure it’s working. Working both in the sense that it does what we say it does, and in the sense that it does what the users want it to do. This is where the communications side really comes in: it’s really important to be clear that users are asking the right questions so they can get the data they think they will be getting. This seems obvious but, as one of my colleagues pointed out the other day, anything that runs as a smooth user experience requires a huge amount of often quite picayune and fiddly design on the other side to make it all look slick–and most importantly, work properly.

The second speaker at Wednesday’s talk was Vanessa Harden, a designer who spoke about the challenge of designing for people who are not usually thought of. Vanessa didn’t really speak about computing very much, though she spoke briefly about one project that led her into designing a website. Mainly she spoke about projects like designing tools for guerrilla gardeners, and working with physicists to help design objects and artworks to help people understand complex concepts like the Doppler shift, the shape and scale of the universe, and the theory of relativity. Vanessa also spoke about the importance of communication, of taking key needs or requirements from users in order to make a really effective design. She highlighted the danger of getting bogged down in users’ overly detailed representations of what they think they will need. Mags also touched on this, though mainly she was focusing on designers getting distracted by ideas of how things should be designed or should be structured, and not thinking about whether a simpler design might be more effective.

But it wasn’t all ‘simplify, simplify’; both speakers also talked about the importance of having a clear understanding of how users actually behave, or what the real-world conditions in which the design will be implemented are. In other words, getting right in there with users and seeing if a design is actually effective. And if in testing it turns out not to be, well, that was one avenue you explored and you’ve learned that something different is required. Whatever you tried can still be kept aside for a project where that concept might work better.

Vanessa’s talk especially reminded me of what I was speaking about in my blog about inventor’s children, and having an abiding fascination for design, for the confluence of objects and ideas. As I thought about this, I began to consider needlework, like knitting or crochet, as a metaphor for computing.

I can sense raised eyebrows amongst you, dear readers, but think about this: needlework and computer programming are both based on algorithms. They both involve the use of iteration, of multiple increments of the same unit being repeated over and over again, in order to create a finished product. On its own, a single crochet stitch is meaningless. On its own, a single binary unit is just a digit. It is only in combination with many other repeated units that they each take on meaning and utility. (I now think of reports I design being raveled like scarves, from balls of shapeless yarn into unified, useful wholes.) They both require incredible precision: a single missed stitch or a misplaced bracket can dog you to the end of your project–or at least, can provide a surprising result.

For me, both processes represent the opportunity to design an incredible range of wildly different objects that, when you look closely enough, are still composed entirely of those tiny iterations. It’s easy to get overwhelmed by the complexity of a very large algorithm, or for that matter, a very confusing crochet pattern. But whatever else they are, needlework and computer programs will always be built on smaller pieces, which are built on smaller pieces, which can always take you right back to that single stitch.