I’ve been teaching, writing, and designing in various capacities for nearly twenty years. Here I share the things that I’ve learned and come to believe during that time, about each of those fields individually but also in the overlaps, which is where I’ve made my career.
Values Across Disciplines
Writing and design have a surprising amount in common. This is because, fundamentally, doing either well requires understanding and caring about people – empathizing with their situations, understanding their needs, and crafting a product that respects and accommodates both.
There are things I’ve come to believe are essential to both great writing and great design.
Don’t waste anyone’s time
“Use the time of a total stranger in such a way that he or she will not feel the time was wasted.” (Kurt Vonnegut)
I read this quote when I was young and it has shaped my writing and my design since. Where Vonnegut was talking about plot and diction, a technical writer might think about scannability and wayfinding and nested headings. The sentiment also holds true in teaching and in product design. As an instructor, I want every single class session to feel vital, every single reading to feel relevant and actionable. As a designer, I want to eliminate any unnecessary or redundant steps or procedures that stand between a user and their goal.
Be a good listener
Listening to people is not an option in writing or design. My first step on any new project is to sit with stakeholders and work together on requirements that will define the scope of the project. Once work starts, I seek feedback from stakeholders early and often to determine whether or not the work to that point conforms to the requirements or if we need a course correction. I involve stakeholders early in every stage of the process, especially if what I’m working on is about them, not just for them (see my work with the Samaritans for the best example of community-centered design).
In the classroom, checking in early is just as important. I listen to what student performance tells me about what they’re learning and what they’re not. Understanding who gets it, who doesn’t, and who needs more practice can make or break a student’s success, especially while it’s still early enough to help rescue struggling students.
Tell a good story
Product development is rich with storytelling. As a product lead, I tell the story of the product for stakeholders through white papers and requirements. As a designer, I tell the story of the product for the user through interactions and microcopy in user interfaces. As a technical writer, I tell stories for all stakeholders through documentation and tutorials.
I also tell stories as a teacher. Students need to fit their courses and material into the larger narratives about the academic career, and teachers are crucial to helping them do that. To keep every day relevant, I help students understand the story of a course and how daily activities like reading, discussion, and practices advance that story. Students should never be uncertain about why they’re being asked to do something – about how each task fits into the larger story of the course – and that depends on framing and narrative cohesiveness that I provide for that work.
Speak a common language
It’s important that all members on a team understand their role, the goals of the project, and the metrics by which effort will be assessed. Without this shared understanding, it’s easy for projects to change scope, lose focus, miss deadlines, and go over-budget.
Stories are crucial for this, and in projects I lead, writing is a crucial component for helping teams stay on the same page. For design, we develop white papers to define the scope of a project and requirements and functional specs help define the scope in steps toward implementation. In teaching, my syllabi are designed to make course goals and scope transparent, while schedules and rubrics help define the pace and the assessment metrics for any work. In both cases, it’s a matter of getting all stakeholders on the same page.
Don’t be afraid to fail
This lines up with “be humble and curious”, but I try to keep my pride in check and not be afraid to fall on my face while trying something new. Rather than trying to project perfectionism, I try new things and embrace failure to demonstrate for product teams or for students how I fail and recover. Trying new methods, tools, and techniques is critical to keep my own sills from growing stagnant, but giving students the opportunity to fail and recover themselves is vital for their own abilities to grow on outside of the classroom.
Design for real life (aka the worst-case scenario)
Instead of treating stress situations as fringe concerns, it’s time we move them to the center of our conversations—to start with our most vulnerable, distracted, and stressed-out users, and then work our way outward. The reasoning is simple: when we make things for people at their worst, they’ll work that much better when people are at their best. (Eric Meyer & Sara Wachter-Boettcher, Design for Real Life)
I design with the methodology laid out in Design for Real Life. It has a lot in common with mobile first and accessibility first methods – by anticipating and designing for the lowest-resolution displays, or users with low vision, or students who don’t have internet access, we place stress cases at the center of our work. This makes is more likely that our product will be as inclusive as possible and meet the needs of as many users as possible out of the gate (with the assumption that support for accessibility is never truly “done”).
Be boring rather than clever
Too much emphasis is placed on a user’s “joy” and “delight”, particularly in product design. This is an easy way to make a good first impression, but it’s not a good way to build a lasting relationship.
As a designer and a teacher, I try to always choose the obvious over the clever. I want to deliver products and experiences that are predictable, reliable, and consistent. If a design pattern works, if a lesson plan works, there’s no need to reinvent the wheel. I recycle everything I can, stealing liberally from design frameworks, open-source repositories, and knowledgeable, reliable sources. This is the easiest way not only to ensure that users and students can utilize / access my products / courses, but also to help save money, prioritize resources, keep projects in scope, and deliver a product on time and on budget.
Be humble and keep learning
I try to admit quickly whenever I’m wrong, and I do my best to admit when I don’t have an answer. I find this to be an important exercise in humility, but as a leader, it’s important to model for those who work with you (or, in the case of students, are learning from you) that it’s okay and normal not to know everything. Admitting that, and demonstrating how I go about finding an answer, has proven to be a powerful teaching tool.
I also try to keep sharpening my skills by paying attention to new trends in teaching and technology, following thought leaders in social media and at conferences, and sharing my work in return.
Be an evidence-based practitioner
This builds on “tell a good story” and “speak a common language”, but it’s crucial that any endeavor have indicators or metrics to determine whether or not objectives are being achieved. Proceeding without a shared understanding of what it means to succeed, or what warning signs to watch out for, can lead to a lack of focus at best.
In product development, I work in the requirements state to identify key performance indicators like average daily users and conversion metrics like sales or newsletter signups. In teaching, I identify the learning indicators based on curricular outcomes that will help me know if students actually understand the material or where they’re falling down. In either case, I’m basing my work on clear, quantifiable signs I can watch for and measure that will let me know if my work is hitting its mark and, if not, where I can make improvements.
Get comfortable saying “no”
One of my biggest challenges as head of product for Eli Review has been pushing back against requests for new features or changes from stakeholders both within and outside of the company. Users make requests all the time and it’s my job to listen to that feedback and determine whether or not it makes sense for our product, and if not, I have to tell them way. The same goes for internal requests – as a company, we throw out ideas all the time, but I’m the team member responsible for maintaining the overall vision and integrity of the product.
This is helped by the work done in “speak a common language”. When we have a white paper that clearly identifies what our product is meant to do and that everyone has agreed upon, it’s much easier for me to point to that document to argue against changes that compromise those purposes. Even so, as product manager, it’s my job to be contrarian and to shut down ideas that compromise the vision or the user experience of our product.
Never assume the work is “done”
This ties closely to “keep learning”, but it’s important to never think of a product or a course as “complete”. Both can easily become stagnant, stale, and obsolete.
With living products, I make sure we’re listening to the constant stream of user feedback because it often has valuable insight on how features might evolve to be more useful and usable. But there are other volatilities to be aware of. Within a company, business goals evolve, as do measures for success. Technology changes can cause features to become stale and inconvenient, making users more inclined to find better solutions.
In the classroom, I rarely teach the same syllabus twice for the exact same reason. New scholarship or methods become available, student experiences on a project can inform how that project changes, and new tools can lead to new teaching needs. As a teacher, I need to continually re-evaluate my methods and materials to stay relevant and useful.
Being able to communicate clearly and effectively through written communication, and understanding how to the rules and patterns of appropriate genres, is a critical skill for anyone in a knowledge-based practice like design or teaching.
My entire career has been spent writing or helping others get better at writing. My graduate education was spent either studying writing theory and practice or working in a writing center where my job was to help writers improve not by focusing on spelling or grammar, but rather on higher concerns like audience and purpose and genre conventions. The curriculum and materials I develop for my own classes, even those ostensibly about technology, are focused around effective communication and technical writing genres like proposals or requirements. I invented and continue to develop a product whose sole purpose is to help writers get better through feedback and revision.
Writing in Product Design
I discuss the variety of genres used in the About Product Design section, but the critical thing to note is that writing guides the product design process at every stage and, by extension, the people who do that writing end up being leaders of that process.
Likewise, the work I do as a copywriter is essential in the actual product. Onboarding content, the microcopy in form labels or button names, and the text in error messages can all make or break not just the user experience of a product, but whether or not those experiences lead to conversions or to users quitting in frustration.
Finally, as a technical writer, I produce user guides, tutorials, and documentation that are also critical to product design. Effective documentation, with clear instructions and supportive images or videos, can make the difference between a satisfying or demotivating user experience. Writing that content, organizing it, and publishing it are highly-specialized skills with writing at the center.
Writing is not only at the heart of good instructional design, as I’ll explain in the About Teaching and Learning Design section, but the teaching of writing is itself a challenge. Learning to write well has more in common with learning math or physics than most people realize – it requires practice. Lots and lots of practice, guided by a good coach. And feedback, lots and lots of feedback.
Whether teaching in a high school, college classroom, or an office full of colleagues, writing improvement is grounded in feedback, revision, and repeated practice of that cycle. My colleagues at Michigan State University and I invented a product designed to facilitate this type of feedback-rich, revision-centric instruction that has proven to help writers improve.
Most importantly, it’s critical to think of writing as a skill that can be learned and improved through practice. It is not a gift bestowed upon humanity by muses, but it is a skill like any other that can be learned and coached and practiced and improved. Anyone can be a good writer.
About Learning Experience Design
Learning Experience Design (LXD) is a relatively new way to approach instructional design. I like to think of it as applying user experience design principles to education. Applying methods from UX-related fields like content strategy, user stories, journey mapping, heuristic evaluation, and usability assessment to the materials we prepare for our classes to the materials we design for students can have a serious impact on how we spend time in classes, the deliverables we create and ask of from students, and our course goals and outcomes.
With this in mind, I like to think of myself as a “full stack” learning experience designer. That term is normally applied to engineers who are qualified in both front- and back-end development (see section About Product Design for more). In my career in education, I’ve reinvented existing courses, designed new courses, helped steer curriculum design, taught classes, and mentored students through independent studies. I’ve used my UX skills in all of this work, including my product management background. I’ve also leveraged all of these skills to build an entire product based on pedagogical principles for teaching writing (Eli Review).
Valuing student experiences
It should seem obvious, but anyone designing instructional material should value the experiences of their students. When planning courses or standing in from of a class, students should be treated as learners and not just consumers of information. When designing materials, I try to get students invested in their learning by giving them opportunities to co-design curriculum or outcomes.
Additionally, I apply the “design for real life” principle to the learning experiences I design. There are many factors that can influence a student’s experience in a course or an academic program – how far they commute, how many children they have, can they afford the course materials, do students have internet access at home. All of these factors can have a serious impact on student experience, and I try to account for them as much as possible.
Designing learning indicators
As with product design and user experience, it’s critical to determine how to measure learning. With product design there are standard indicators like daily active users or conversions, but measuring learning is a much more serious challenge. As a learning experience designer, it’s my job to figure out what those indicators of learning are, how to watch for them, how to report them, and then how to act when they’re found. For example, what are the red flags to tell me a student isn’t getting it? Where do I need to make interventions?
It’s unacceptable to not know if students are getting better. Many instructors try to intuit whether or not what they’re doing is making a difference, but it does a disservice to students and instructors if there are no success conditions defined. Worse, if I as an instructor can’t prove that what I’m doing as a measurable impact on student improvement, I leave myself open to being replaced by machines that can show that (however bad they are at it).
Teaching materials are technical writing
The materials I design for my courses are an important type of technical writing. A syllabus is documentation for my course; a rubric is a recipe for a project; a schedule is a schedule. These are all texts with a purpose and they need to be designed that way.
Likewise, I develop a content strategy and information architecture for deploying these materials. They need to be findable, discoverable, searchable. They need to be easy to scan to find critical information. And most importantly, they need to be accessible, which most Word documents or PDFs we publish to our learning management systems are not. These are all technical considerations that are just as important as other pedagogical considerations in learning experience design.
Applying LXD to product design
Principles of learning experience design played a great role in the development of our product, Eli Review. Every feature in Eli is based in an extension of pedagogy, even those that work against the immediate interest of teachers and students.
For example, Eli places an emphasis on peer feedback in the writing improvement process. We designed Eli explicitly to prevent instructors from participating in this process, because research shows that students will ignore peer feedback in favor of instructor feedback. Eli does not let instructors do this, instead leaving them out of the feedback process until peer feedback has been received and processed and writers are ready to revise. Our design choice frustrates instructors who want to give feedback, but Eli prevents it because it is ineffective pedagogy.
About Product Design
My background in developing products also gives me the background of a full-stack developer: I have led the development of products from the earliest invention, through detailed specs, to building interfaces, designing databases, writing code, and preparing documentation.
These are some of the values I’ve taken from that work developing products.
Start documentation on day one
Documentation is crucial not just for a great user experience but also for internal organization and coordination of projects and, all too often, it’s left until the very end of a design process, until after developers have “completed” their work which, in many cases, is too late.
We technical writers responsible for documentation are too valuable to wait until the end of a project. We should be invited into the process from the beginning not so that we’re aware of the product being developed, but to invite our input on requirements, the writing of content for the product (onboarding text, button labels, other microcopy), develop a controlled vocabulary, and to help design workflows for system procedures with users in mind. If the people responsible for creating support materials are able to address future issues while the app is still in development, users can avoid many of those problems altogether.
Assist humans, don’t replace them
As product designers, we have the ability to develop ethical products that respect humans rather than putting them out of work. As people who understand activities and interactions, we can design ways to improve those activities and how humans experience them, or lead them to make better decisions, or make smarter interventions. We didn’t want Eli Review to be an automatic feedback tool that could eventually replace teachers; instead, we augment teachers with real-time data about student performance and indicators for where interventions might be most effective, something they couldn’t do on their own.
Define the product
Related to “speak a common language”, projects without clear specifications are susceptible to feature creep, scope changes, and budget overruns. As a product designer and a technical writer, I define the scope with white papers, requirements, functional specifications, user stories, workflow diagrams, and documented user research. This is the work that must be completed before a single line of code gets written, and these documents themselves can and should be tested to validate their ideas before going into production.
As they say in construction, measure twice, cut once.
Maintain what you’ve built
Calling back to “never assume the work is done”, any product that isn’t designed with long-term support and maintenance in mind is troubled from the start. Logistical issues like security and uptime need to be addressed, but so do pragmatic issues like library updates, server upgrades, etc. My work as a product manage isn’t done when the product ships; like the product, my job isn’t done until the product is sunsetted.