One of the survival skills you learn in grad school is how to take one idea and make a lot of hay out of it. I wrote a case study about the time UX struggles we had at Eli Review and I turned it into a fun 2018 UX advent calendar post, a talk at the 2019 World Information Architecture Day, and another talk at Ignite UX MI 2019. Lastly, when an open call came out for the March 2019 open issue of User Experience Magazine, I wrote a proposal for a journal-length article.
The article touches on many of the important points of the previous presentations, but with the help of the UXPA editorial team, I was able to frame it in a way that cut to the heart of the problem – that a flawed information architecture built on flawed assumptions can have frustrating and expensive consequences for the user experience and for future development:
The user experience of most web-based applications begins well below the interface, all the way down to fields in a database. Examining how systems and users experience time prove this point dramatically. Think about how messy time can be—time zones, leap years, recurring events. As the creators of educational technology, our team learned the hard way about failing to consider the UX implications of time—not just about how time works in technology, but also how our users experienced it in our UI. What follows are some of the technical issues that UX designers should consider about time, along with takeaways and specific methods that can be used to keep the user experience of time at the top-of-mind during product development.
I wrote the original draft in Google Docs with feedback from Bill Hart-Davidson and then substantial editorial guidance from Deirdre McGruder. The final piece was published on March 30, 2019. See below for the full proposal.
See the completed piece in User Experience Magazine.
What will you write about and how will you tell the story? One or two paragraphs describing the article and how you will illustrate your ideas with strong examples.
I recently wrote a case study for my portfolio about biases I had and assumptions I made about how time works that had profound implications for the user experience of our product. One of these biases is an assumption about all of our users being in Eastern Standard Time and failing to accommodate users just a few hundred miles from us, let alone the other side of the globe. We learned that hard way that measuring and displaying time was central to our user experience and had to completely rebuild how our system handled that data.
I believe I can turn this case study into a compelling article. It tells the story of a serious UX failure, how I learned from it, and how I worked with our engineers to fix it. I have concrete user stories and examples in before/after comparisons of interfaces and database diagrams. The story of this failure offers a “learn from my mistakes” example for other practitioners. But it also offers lessons for all designers about the nature of time and how it works within systems and the kind of questions that must be asked of engineers in order to make sure user’s unique time-related needs are addressed at the system level.
What will readers learn from your article? A summary of the main points you will make.
Readers will learn practical information about how time works in online systems and the implications of decisions about the handling of time for UX. This is critical information to decide at the beginning of a product that involve stakeholders and developers and readers will get a sense of what questions to ask to ward off future breakdowns. The use cases presented in the article will provide examples of how designers can anticipate time-related needs their users might have. The user interface examples included will also serve as models for how they might address some of these use case issues in their own interfaces.
Why are you the right person to write this article? Briefly, describe your experience and expertise in the topic.
I work with a small team where I am the Head of Product but also the UI designer, the information architect, and the QA tester, so I bear full responsibility for the time difficulties our users experienced. It was also my responsibility to fix the problem, which required extensive research to understand how our users experienced time and the edge cases that were particularly troublesome. I also had to do study up on the technical considerations of time, particularly storing time values in a database and finding out how to keep timezone data fresh as zones change over time. As a result, I believe I can offer readers unique insight into the UX of time from the interface level all the way down to server and database implications.