Establishing Baseline Workflows
I had the opportunity to work with my colleague, Matt Martin, on an interesting and challenging project. We were tasked with determining the primary user experience workflows within JSTOR. The project was interesting because it was up to Matt and I to define the workflow based on the site’s web analytics. The challenging aspect of the project was for Matt and I to learn to use and interpret Adobe Analytics (formerly Site Catalyst) correctly without relying too heavily on our Analytics team. We learned to question our assumptions. We redefined our understanding of workflows. Were workflows more than usage? We needed to factor business objectives and goals with site usage. We then needed to present our finding in way that would be understood with an audience with a variety of analytics expertise. The outcome was better than expected. Not only did Matt and I learn a lot about Adobe Analytics and our business objects, we learned how to present really complicated workflows in clear and straightforward diagrams.
Read More ›
Evaluating the Experience
One of my responsibilities as the Associate Manager of User Experience Design at JSTOR is to run professional development activities for the user experience team and the graphic designers. The professional development activities can be directly related to project work we are doing or skills we need to practice. My favorite activity that I designed for the group was an exercise around practicing the evaluation of an experience. Because we work in technology, we often forget than an experience can be in person, too. To that end, I invited the entire team to spend an afternoon exploring the University of Michigan Museum of Art in Ann Arbor, MI. The activity was open-ended. The team was encouraged to interpret “evaluate the experience” in a museum during a 2-hour time period. Each member was given a notebook to take notes and record observations. The only instruction I gave to all of them was that we would me the following day to share our experiences. The results were amazing. Almost every team member focused on a different aspect of a museum “experience.” Some of the team studied the flow of the exhibits, others looked at instructions within the museum, a few looked at […]
Read More ›
Design Jams
Design Jams Will Evans’ Design Studio Methodology revolutionized how I use a design jam activity to gain stakeholder buy-in, end-user insights, and product design direction. Using the Design Studio templates, I can focus the participants during the activity around small, discrete problems to solve. The primary role I assume during the design jams is that of facilitator. Often the individuals participating in the Design Jams do not perceive themselves as “designers” and can be intimidated about the process. I spend a considerable amount of time reassuring them that if they can draw a square then they have enough skill to participate. I also spend time listening to all of the ideas that are suggested. By giving stakeholders and end-users a platform to participate in the design process, we are often able to reach buy-in and an agreed upon direction faster and more efficiently. View here: Design Jams
Read More ›
Selling the Product (Before There is a Product)
How do you get the market excited about a new Product when you’re at the very beginning of the development process? You create a video of what you think the experience will be. I collaborated with Wendi Strang-Frost to create a video based on a high-fidelity prototype based on JSTOR’s vision of the new product, Books. The video needed strike a balance between the excitement of the content and the constraints of an existing platform. And because the video would be shown for the first-time in front of potential publisher partners, we could not over promise features. The result is a two-minute video to generate excitement about the new product, Books. View here: Books @ JSTOR
Read More ›
Personas
Using the data from usability testing, site analytics, user interviews, and other resources, personas can be created to help teams keep focused on their primary end-user’s needs and goals. It is especially useful to have personas when an agile team is developing the backlog and writing user-stories to plan and structure the work. Final design created by a visual designer.
Read More ›
The Advantage of Sketching
I find the main advantage of sketching is that I typically have not invested too much time in creating a deliverable that may or may not be correct. Sketching enables me to take enough time to think through a workflow, interactions, or concepts without investing the time and effort to create a formal deliverable. I can sketch on scrap paper, a Post-It, or the whiteboard. Because it is not finished and polished, I can share the sketch team members to solicit feedback and iterate through the design process. And the best part, if I’m completely off base in my design direction, it’s easier for me to change and try a new direction. I’m sharing an example of a sketching fail. The goal of the assignment was to capture the existing behavior of the JSTOR platform as conceptual model. While the model ultimately didn’t work to convey the information we needed, it was a useful starting point to spark discussions in the team.
Read More ›
“Just Enough” Wireframe
Part of the allure in joining JSTOR is that they are an agile shop. Theoretically, I understood the mechanics of agile and scrum in particular. But I didn’t understand how user experience deliverables fit into the work of scrum development teams. I was used to waterfall methodology, mapping out an entire experience in advance of the technical build. In addition, I was accustomed to working in an agency model in which the agency works in parallel of the client and when our work is complete, we flip the switch on. I needed to adapt my deliverables to the dev teams to be leaner and I needed to be able to make them faster. Instead of writing 100+ pages of functional specifications that contained all of the wireframes and annotations for the entire experience, the wireframe needed to reflect only what contained in a single development user story. I could then work with the dev team to clarify all of the edge cases during sprint planning sessions, enabling them to work faster and more efficiently.
Read More ›
