In recent years, more and more companies have been embracing a design-centric ethos. As a result, user experience design has acquired enormous momentum. In order to fulfill the rising demand of UX professionals, world-class programs are being offered by design schools around the world. Just a few months ago, I graduated from one such program at the University of Michigan, Ann Arbor. During my two years of studies in the User Experience Design Program, I had the opportunity to intern at Cooper, The Understanding Group, and The Design Clinic, a design service initiative led by the School of Information.
While being exposed to a professional practice alongside a student perspective by taking design courses, I realized certain gaps between the real world and the academic world. The existence of these gaps used to be one of the hot topics I would discuss with my peers. Today, as I look back at my experiences through the lens of a user experience designer, there are a number of gaps that are easily recognizable.
At my school, a design challenge event also known as a “Design Jam” is very common. It serves as an engaging platform for students to collaborate and brainstorm solutions to interesting problems. Design Jams are also a smooth escape for students from a hectic semester with a promise of free food (see Figure 1). Like a lot of my friends, I participated in quite a few of these Jams. From designing a more “visible” Google Wallet, to a futuristic meeting room, Design Jams always had a competitive atmosphere and participating in them certainly shaped me into a better team player.
But after a couple of challenges, I realized that I was being deprived of the very basic principles of user experience design. These challenges rarely required us to conduct user research with the people for whom we were designing the solutions. Instead of empathizing with users and understanding the real problem, we were falling prey to a pretentious competition. We were not looking for answers to the right questions—we thought about “how” rather than “why”. Everyone, including myself, was trying to come up with the coolest idea only to impress the judges of the event. And more often than not, these judges were representatives of companies looking for a diamond in the rough. Our design decisions were not really catering to users’ actual problems and it felt like I was disrespecting the user-centered design process.
As designers we often come across situations when we have to choose one idea over the others. While interning at Cooper, I learned the importance of the decision-making process not only at a feature level, but also at a much more granular level of interactions and micro-interactions. The biggest takeaway was that for a design to be successful, all of the design decisions we make must be based on end user—and in some situations—stakeholder requirements. This not only helps in building the right product but also in justifying the design. In my experience with Design Jams and most of the courses I had taken, I sensed a lack of attention toward the relationship between design decisions and research findings. Students often get carried away in delivering a “cool” design rather than one that is usable and informed.
Of all the courses in the design program, the most challenging were those that required us to deliver a final project presentation. During the presentations we were expected to walk the audience through our process, the problem statement, challenges faced, and the solutions we came up with (see Figure 2). After doing a handful of these presentations at school, I felt confident and prepared for a real-world client presentation. My confidence was soon put to the test.
During my summer internship I had an opportunity to present some of my designs to clients. During the preparation, as I observed my teammates tailoring their portions of the presentation, I soon realized how different client presentations were from those at school. There was a disconnect: I was preparing points on the process I went through while the rest of the team was getting ready to show how the new design would make the user’s life easier.
After a couple of client interactions I learned an important lesson: the clients don’t want to hear about the process of how you went from user research to hi-fidelity mockups. They want to hear how well the design solves their problems. In fact, they would rarely want to listen to the designers’ process from concept to finalized design. Client presentations are less about the designer’s journey and more about communicating the user’s journey through the design solutions.
It is not too hard to figure out why presenting for the first time to a real client was so tough even after having done plenty of presentations in school. First, the audience for project presentations in school was primarily my peers––who were competing against me for a better grade, and a professor––who was going to give me grades. Secondly, in a process-focused curriculum, like all of my peers I ended up describing the process in greater details rather than discussing how the design decisions would affect the users. As a result, I never really presented designs as I would for a real client. There was less focus on what was being communicated and to whom and more on receiving high scores. I like to think that communicating design is as important as the design itself.
Designing software excites me, but what excites me even more is applying the same principles of user experience to the design of objects in the physical world. On one school project we worked on designing a spice dispenser for visually impaired people. It was interesting to see how design concepts of feedback, mental model, mapping affordances, and visibility apply to physical objects in the same way as they would to a website or mobile app. We performed usability tests on a 3D printed model of the dispenser with a group of visually impaired users and received really helpful insights into the user behavior and patterns. We also got feedback from industry experts, professors, and peers with regards to materials, internal mechanisms, feedback cycles, and more (see Figure 3). Unfortunately we received all of this feedback during our final project critique towards the end of the semester. While part of our final report had an account of this feedback, it was never used to better our original design. Even though the feedback was extremely meaningful, without putting it to work for the design, it was ultimately not valuable or productive.
Design critique is constructive only if the feedback can be put to use. It is well accepted within the industry that an iterative process results in a better design. I find it surprising that like the spice dispenser project, most other academic projects had the critique session at the end of the semester, leaving no room for students to redesign and rebuild.
When I was a design consultant at Design Clinic, it was a young design service initiative led by students. Project management protocols had not yet been adopted, and there was room for students to experiment with concepts learned in school. Here, I worked on a college planning and tracking application for high school students. Both the client and my team agreed upon a process to achieve the deliverable of a mid-fidelity mockup of the mobile app. With the target set and the schedule outlined, we took a deep-dive into the project to work out a good solution. We made a mistake at the start in not paying enough attention to its documentation. As a result, we spent extra time having to recall and document decisions that had been made almost a month earlier (see Figure 4).
I learned that documentation is a crucial part of the process that needs to be done at every stage. Plus, it’s not just about documenting only those sketches and ideas that make their way to the final design, but of keeping a record of all the rejected ideas as well. Because there will come a time when the client will discuss an idea that you had rejected long ago, but you don’t remember why.
With most academic projects, documentation is the last assignment for the semester, a final report for upload to the class website. Needless to say, many students start putting the documentation together only on the last day of the project. In my industry experience, I had to hand over designs to visual designers, developers, and business analysts. And for each of these instances I had to document my designs for easier communication.
Over time, I have come to realize that learning design processes is extremely important. But it is not sufficient to groom a budding designer stepping into the industry. This account of my experiences and observations is meant to kindle a conversation among design students, professors, and industry professionals on how to make UX education even better than it is today. Perhaps one way of providing students with a more holistic experience of the design process would be having them work on projects that span multiple courses, each of which teaches different aspects of the process. By having projects centered on actual users and real problems, the focus can be shifted from winning good grades to winning the hearts of the users.