Decorative image
Decorative image

Much of our work as user experience designers is understanding the whys and why nots of our audiences’ decision making. In a previous post, I explored why people decide to switch or stay with products, focusing mainly on circumstances, the “where” and “when” of a job. The circumstances in which a job is done is an example of a “Job driver”. Job drivers are influences external to the job itself that cause people to take an action over another. These job drivers break down into three categories: the job actors' attitudes, background, and circumstances (Wunker, 2017).

Table listing down Attitudes, Background, and Circumstances
Table listing down Attitudes, Background, and Circumstances

Attitude is a person’s positive or negative evaluation of place, person, situation, activity, etc (Eagly & Chaiken, 1993). For simplicity's sake, I will abstract these and call them “an object”. These attitudes split into three areas: affective (feelings), behavioral (the effect of the attitude on behavior), and cognitive (belief and knowledge) (Rosenberg & Hovland, 1960). I will be using this model to describe how understanding the interrelationships of these could start to provide both a human and outcome-driven mindset for our design teams and allow us to be much more deliberate with the types of features we pursue. …


Designing for education can be challenging, yet extremely rewarding. Knowing that every time a student engages with your product they will get just a little bit smarter and closer to their aspirations bring a true sense of purpose. This incremental growth that you and other designers of educational experiences have created and used by educators, builds over time. This creates opportunities for students and hopefully helps to make the world a little smarter than yesterday. This passion for education is what has kept me in the industry for more than a decade, and will continue to inspire me as a designer and problem solver. …


As UX practitioners, usability studies are commonplace. However, articulating our findings in a way that effectively describes the urgency of the issues to be acted on is not always straightforward. Below I will discuss how we could use a FIRE Score, a set of indicators that adds more context to a problem, in order to help product groups understand what issues need to get resolved immediately and what may be able to wait until later.

At various points of the product life-cycle, a team will receive signals of how successful customers are accomplishing tasks within their system. Ideally, any issues in their flow will be uncovered early on during their usability research. If not, they will likely hear about them soon after through user behavior data, customer service calls, NPS, or countless other methods to observe signals from their users. …


As a manager of User Experience Designers, one of my jobs is to encourage them to come up with experimentation methods for gaining the most amount of learning for the least amount of time and effort. Doing this keeps our iteration cycles lean allowing us to act on our learnings quickly. For this reason, coding is sometimes seen as a risk during early solution discovery, due to the assumption that it will result in increased iteration cycles. In most cases, I do agree, but the “to code or not code” conversation is much more nuanced than a simple yes or no. …


Knowing that you built a better mousetrap, or in this case a shoelace, why do people fail to switch? In this post, I will try to explain how situational context might serve as a driver for people deciding to persist with a product they are currently using or switching over to something else.

Anyone who knows me well knows that I have loyalty towards Puma sneakers that stems back to my college years when I snagged a coding project that they were offering in exchange for…you guessed it sneakers! What can I say, they had a low budget and, at the time, I would have probably spent my money on sneakers anyway. …


Image Credit: Pixabay

As I’ve let go of being an individual contributor and focused my time towards a more formal leadership role, I’ve developed an appreciation for the art of conversation amongst product teams.

Conversations are a critical part of an organization’s toolbox. On average, people have 1.2 meetings per day. Managers have around 3 meetings. That adds up to about 45 hours worth of meetings per month for a manager. That equates to a lot speaking, listening, and responding, but that doesn’t necessarily equate to shared understanding.

A team’s most important tool

When we think about product design tools, words like Jira, Sketch, or InVision quickly come to mind. You might also think about methods such as journey mapping, user testing, and other approaches that create tangible artifacts. There is one tool, however, that is likely one of the most powerful tools in your product design tool chest which people tend to forget.


Two of the biggest troublemakers that can impact your product design project are a lack of team alignment and a lack of awareness of feasibility. In this article, I will reference these two scoundrels as “The What” and “The How”.

Image for post
Image for post
  • The What: a lack of stakeholder alignment on the requirements of the initiative.
  • The How: a skewed understanding of what it would require to execute an initiative. This typically involves development execution but could include design, and content requirements.

Having a keen understanding of your certainty on both “The What” and “The How” will help you to better prepare activities that will reduce your chances of being knocked off course by inevitable setbacks. …


In the following series of articles, I will unpack various personal experiences that I have come across, and what I’ve been doing to help alleviate some of the issues that I’ve been confronted with.

There is more to “Design” than pretty pictures on the screen. It runs much deeper. It is problem-solving, driving toward a solution that elicits an outcome an organization is focusing on. These outcomes could affect a variety of states like emotion, trust, engagement, or in my case learning. Designing is difficult, but not all design problems are created equal.

Over the course of the last 2-years, Macmillan Learning has strapped a jetpack on learning science, research, and design; propelling our team’s reach across the organization as we co-build digital products for higher education, with the help of some brilliant stakeholders, and amazing students and instructors. While this is exciting, I will admit, it has come with some lessons learned that I’ve been chipping away little by little. How wouldn’t it? Design is messy, and as you scale design, it is bound to get even messier. …


When designing educational experiences, it is important to craft interfaces that are not only intuitive, but enable learning while minimizing any extraneous cognitive load to the student (Chandler & Sweller 1991; Plass et al. 2010) Unfortunately, good Human Centered Design practices do not always support learner outcomes — and that’s where Learning Sciences comes in. While design principles, such as Gestalt are important, the ability to integrate cognitive learning principles to the features and products we build are integral to creating delightful and effective learning experiences.

Before I start to speak about technology and screens, I’d like you to think about the last time you opened up a textbook. As you flipped through the pages you would have likely seen an assortment of images, illustrations, charts, tables, assessments, and many other features that complement the words on the page. …


Once a year the entire sales staff at Macmillan Learning converges at the National Sales Meeting. Our sales staff is comprised of talented individuals that are tasked with pitching the products that we create and interacting with customers that span from Hawaii to New Jersey on an everyday basis. I was given the opportunity to travel to the conference and tap into the hive’s mind to see what they’ve been hearing and thinking about while on the field.

With the help of our department head, we were able to get our team on the invite list, but there were some conditions. We would have 30 minutes and less than 10 of the top generalist would be invited to attend. Although ambitious, I saw this as an opportunity to not only learn, but also demonstrate the speed and agility that our product and design team is capable of. To our advantage we were given an early afternoon slot on day one, which meant we would have almost 3 business days. …

About

Alex Britez

Designer, Developer, Dad & maker of things that teach stuff. Director of UX at Macmillan Learning & Adjunct Instructor at NYU’s Digital Media for Learning

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store