The interdisciplinary team at Scaling Up Digital Design Studies (SUDDS) was brought together last November by Jere Confrey to build a learning map web application with an accompanying assessment and reporting system for middle school math. The team was new, and we were yet to gain a deeper understanding of the project and to learn how to work together.
As a UX/UI and visual designer, I was looking forward to being part of a team. Several years of freelance work prepared me to handle and to enjoy wearing many hats on the job, but I yearned for an experience of teamwork where ideas are born and brainstormed through a collective effort. And that was exactly what I was going to get!
Several months after the SUDDS project began, I attended a user-experience (UX) workshop at PointSource, a mobile app design and development firm in Raleigh. They place a great deal of emphasis on the process they refer to as co-design. At the onset of a project, an interdisciplinary team is formed that may consist of a UX designer, a visual designer, a developer, and a business analyst or project manager. The team members meet for co-design sessions, in which they approach the project from various angles according to their areas of expertise. The process that the leaders of the PointSource workshop described sounded very familiar; that was exactly how we worked at SUDDS!
Co-design may at times be challenging for designers. We carry around a sense of anxiety about design-by-committee as a recipe for disaster; and on a team consisting of non-designers, we may have a difficult time loosening up control over the creative direction. But overcoming those inhibitions is well worth the effort, especially given that co-design is really not at all the same as design-by-committee, although they may seem similar at first. Let me explain.
Design-by-committee happens when product features are added or changed arbitrarily—often as an afterthought—to appease stakeholders; it happens when design decisions are made for political reasons, but are not necessarily well-grounded in the user-experience, technical, or design requirements of the product. Co-design, on the other hand, invites product team members and users to the table early on. At SUDDS, those groups include our team professionals with various areas of expertise and the two major segments of our target audience: middle school teachers and students.
Co-design as an approach to designing a product fits in very well with a broader idea of agile product/software development, which we embrace. Product development according to agile methodology is carried out in short cycles (called sprints) that support incremental changes through product iterations and testing. Product direction is therefore frequently assessed and can pivot in response to feedback. While feedback coming from user testing is critical in this context, co-design sets up an environment for accommodating feedback from various professional disciplines coming together to build the product. That includes feedback from UX, UI, and visual designers, developers, product managers, and stakeholders.
At SUDDS, we start out by constructing user stories, which then guide the wireframing, mocking up, and prototyping of specific features and modules of the application. A team consisting of software engineers, project coordinator, learning scientists, psychometrician, and me as the UX/UI/visual designer (or any combination of the team members depending on the aspect of the project) meets frequently to vet every step and iteration until we arrive at a solution that is ready to be tested with our user groups. Yes, compromises are inevitable, but we make sure that the user’s needs remain front and center, that we do not sacrifice the significance of the content and its research-driven structure, that we adhere to principles of design clarity and consistency, and that we come up with implementable solutions that can be engineered up to modern software development standards.
In his book, Responsive Web Design, Ethan Marcotte introduces a humorous term of designopment to describe a hybrid phase in product development, when the boundaries between design and development dissolve; when software development thinking is injected into the design process, and when design continues into the coding phase while prototyping takes place. I think co-design is an expansion of designopment into earlier phases of building a product; it blurs the lines between defining and designing a product on the one hand, and between its design and development on the other. And that’s what we do at SUDDS.