I’m in the throes of designing a new help desk for our department that will serve to triage help tickets for approximately 15,000 employees. This has been a major undertaking, and retaining the confidence that I can get it done has been a major challenge. However, it’s also been a really great exercise in forcing me to be introspective about how I design my own ethics and culture into the system.
When we design and build systems for ourselves, we design for what we need, and if you’re like me, you also aim to design for simplicity and the least work possible that still accomplishes your end goal. When I’m designing for myself, I find that I am more willing to let go of a feature I thought I needed because another one will do the job okay, and okay was enough, especially if it means less work for me.
Designing for ourselves in a way is easier than designing for someone else. You essentially know what you need; there’s no guess work or communication gap. Yes, we can get caught up in semantics about how we may not actually understand what we need, and thus you may build something that doesn’t achieve the end goal you had. But hopefully, in the process, you evolve and learn to design and build what you really need.
Also, designing for ourselves forces us to let go on the complex and unnecessary features and build a more simple product that will hopefully be easier to maintain over time. I do not know a time while working in libraries where we (library folk) were not hooting and hollering about the awfulness of the library technology ecosystem. As I mentioned, I’m in the depths of designing a new service desk for my team (in JIRA Service Desk), and I find myself asking “Do we REALLY need this? Can this complex setup be accomplished through a different, simpler method? Can we maximize the use of this setup and use it in more than just one functional way?” When I have to do all the legwork, I think more carefully about essentials and nice-to-haves than when we hired someone else and I was the “ideas person” – and probably much less flexible on the tedious items.
If the load that I carry and my intimate connection to the build force me to think differently about what we do and don’t need, this suggests that maybe we have the wrong people designing library systems. Or at least maybe we don’t have the right people involved throughout the design and build process. Vendors need to include librarians who work in the trenches in the design process. There needs to be representation from the academic, public, corporate, museum, medical, special, etc. communities, at a level that is more than just “We’re looking for feedback we might incorporate in the future!” I don’t yet have an answer to how we can accomplish that, but I have ideas on where to start. Stay tuned for “Why you should leave your library and work for the ‘Dark Side.’”
The flip side to this is that maybe my intimate connection with the workload also encourages me to overlook and take shortcuts that seem fine but really ought to be examined carefully. What comes to mind is a presentation I refer to frequently: Andreas Orphanides’ Code4Lib 2016 talk Architecture is politics: The power and the perils of systems design. Design persuades; system design reflects the designer’s values and the cultural context [Lesson 2 in Andreas’ talk].
Fortunately for me, this came to light while I’m still in the middle of the design process. While not an ideal time because I’ve already done a lot of work, the opportunity to step back, adjust and try again sits in perfect reach. I’ve started reexamining our workflows, frontend and backend; it’s going to take more time, had I thought about the shortcuts I was making sooner and the impact they had on the user experience maybe I’d have less reexamining to do.
When we design for ourselves, how often do we make a compromise on something because it makes the build easier? Does our desire to just get the job done cause us to drop features that might have made the design stronger, but leaving it out meant less work in the end? If someone else was building your design, would you demand that that feature be included – even though it’s difficult to do? Does our intimate connection with the system design encourage us to continue to build in poor values? Can we learn to be more empathetic  in our design process when we’re designing for ourselves?
I hope I’ve encouraged you to consider what you may be missing when you design a system for yourself; what habits you’re creating that will be an influence when you design a system for another.