"product design" entries
Kathryn McElroy on IBM’s design approach
The O’Reilly Design Podcast: Prototyping for digital and physical, IBM’s bet on design, and diversity in design.
Subscribe to the O’Reilly Design Podcast, our podcast exploring how experience design — and experience designers — are shaping business, the Internet of Things, and other domains.
In this week’s Design Podcast, I sit down with Kathryn McElroy, design lead on IBM’s Watson team. McElroy will be be speaking at O’Reilly’s inaugural Design Conference in January. In this episode, we talk about prototyping for digital and physical, design and diversity, and what it’s like working at IBM.
Here are a few highlights from our conversation:
I see the shift from an engineering feature-based product design to a user-centered product design across a 380,000 person company to be the most challenging but most impactful place that I can work. On a day-to-day basis, how this comes through is how we interact with our teams. As designers coming into this ecosystem, a lot of these people haven’t really heard about user-centered design until they come to our design boot camps here in Austin.That’s when we bring all of our product teams together—the business people, the engineers, and the designers—to center around their product and think about it from the user’s point of view. … What’s the most interesting about this is just the fact that it’s at this mind-boggling scale.
Specifically for physical prototyping, I learned mostly self-taught during my MFA program. I had a couple of great classes where we were focused on building electronics, and that was the first time I was introduced to it. I’ve only been doing it for three years, but it’s something you can learn on your own. There’s so many people with guidance out on the Internet and are willing to help you.
Aaron Irizarry on Nasdaq’s journey to embrace product design
The O'Reilly Radar Podcast: Getting a seat at the table is one thing; understanding what to do with it is way more important.
Subscribe to the O’Reilly Radar Podcast to track the technologies and people that will shape our world in the years to come.
In this week’s episode of the Radar Podcast, O’Reilly’s Mary Treseler chats with Aaron Irizarry, director of user experience for Nasdaq product design, about Nasdaq’s journey to become a design-driven organization.
Irizarry also talks about the best ways to have solid conversations about the designs you’re working on, and why getting a seat at the proverbial table isn’t the endgame. He’ll be speaking about these topics and more at the O’Reilly Design Conference, January 19-22, 2016, in San Francisco.
Here are a few snippets from their conversation:
It’s really interesting to see an organization that didn’t have a product design team as of, what, 2011, I believe, see the need for that, bring someone in, hire them to establish a team, which is my boss Chris, and then see just the transition and the growth within the company, and how they embraced product design.
The more we delivered, the more we built equity within the company to be able to kind of have more of a say. … What has really helped us is that we didn’t just focus on getting a seat at the table. We focused on what to do when we have that seat, and how we keep that seat and bring others to the table as well. Read more…
How the IoT will transform manufacturing
The products of the future will impact not just factories, but all aspects of business.
Register now for Solid Amsterdam, October 28, 2015, where Dirk Slama will present the session “Managing the ‘Clash of Two Worlds’ in the IoT.” Editor’s note: this post is an excerpt from “Enterprise IoT: Strategies and Best Practices for Connected Products and Services,” by Dirk Slama, Frank Puhlmann, Jim Morrish, and Rishi M. Bhatnagar.
In some cases, a distinction is made between the industrial IoT and the consumer IoT. But when we talk about “Enterprise IoT,” our focus is less about specific application domains and more about openness and integration maturity.
Here, we will take a closer look at some of the more industrial applications of Enterprise IoT, starting with a discussion about how IoT will transform manufacturing from the perspective of both product engineering and production technology.
Integrated production for integrated products
We believe that the IoT will have two main areas of impact on the current manufacturing landscape. The first concerns the organizational structure that is required to produce truly integrated IoT solutions. The IoT involves a clash between two worlds in which those in the machine camp and those in the Internet camp will be required to work together to create products that combine physical products with Internet-based application services. In an IoT world, many companies will discover that being just a manufacturing company or just an Internet company will no longer be sufficient; they will need to become both — or become subsumed in an ecosystem in which they play a smaller role. Read more…
Designing at Nasdaq
The O’Reilly Design Podcast: Aaron Irizarry on getting and keeping a seat at the table.
Subscribe to the O’Reilly Design Podcast to explore how experience design — and experience designers — are shaping business, the Internet of Things, and other domains.
Welcome to the inaugural episode of our newly launched O’Reilly Design Podcast. In this podcast episode, I chat with Aaron Irizarry. Irizarry is the director of UX for product design at Nasdaq, co-author of “Discussing Design” with Adam Connor, and a member of the program committee for O’Reilly’s Design Conference.
Design at Nasdaq: A growing team
I first noted Nasdaq’s commitment to design when talking to Irizarry about his book and the design conference hosted by Nasdaq that Irizarry helps develop:
It’s interesting to see an organization that didn’t have a product design team as of, what — 2011, I believe. To see the need for that, bring someone in, hire them to establish a team (which is my boss, Chris), and then see just the transition and the growth within the company, and how they embraced product design. We had to work a lot, and really educate and pitch in the beginning, explain to them the value of certain aspects of the job we were doing, whether that was research, usability, testing, why we were wanting to do more design of browser and rapid prototyping, and things like that.
…
We believe we’re helping structure and build, and I think we still have work to do as a design-led organization. We recently did our Pro/Design conference in New York. Our opening speaker was the president of Nasdaq, and to hear her reference the design team’s research, and to be in marketing meetings, and discussing the personas that we created, and to hear the president of Nasdaq speak about these kind of artifacts and items that we feel are crucial to design and the design process, it was a mark for us like, ‘We’re really starting to make a mark here. We’re starting to show the value of what these things are,’ not just because we want design, but we believe that this approach to design is going to be really good for the product, and in the end, good for the business. Read more…
How to conduct a Design Sprint
Design Sprints bring clarity to your roadmap to kickstart and obtain initial validation for product design work.
Download a free copy of “The New Design Fundamentals” ebook, a curated collection of chapters from our Design library. Note: this post is an excerpt from “Design Sprint,” by Richard Banfield, C. Todd Lombardo, and Trace Wax, which is included in the curated collection.
A Design Sprint is a flexible product design framework that serves to maximize the chances of making something people want. It is an intense effort conducted by a small team, where the results will set the direction for a product or service.
The Design Sprint consists of five discrete phases:
- Understand (review background and user insights)
- Diverge (brainstorm what’s possible)
- Converge (rank solutions, pick one)
- Prototype (create a minimum viable concept)
- Test (validate with users)
A Design Sprint reduces the risk of downstream mistakes and generates vision-led goals the team can use to measure their success. For the purpose of this book, we’ll focus on digital products since our direct experience lies in that arena, though the Design Sprint has roots in gaming and architecture, and many industries have employed them successfully. Read more…
Empathy is a state of mind, not a specific technique
A design process paved with empathic observations will lead you, slowly and iteratively, to a better product.
Editor’s note: this post was originally published on the author’s blog, Exploring the world beyond mobile; this lightly edited version is republished here with permission.
If I’m ever asked what’s most important in UX design, I always reply “empathy.” It’s the core meta attribute, the driver that motivates everything else. Empathy encourages you to understand who uses your product, forces you to ask deeper questions, and motivates the many redesigns you go through to get a product right.
But empathy is a vague concept that isn’t strongly appreciated by others. There have been times when talking to product managers that my empathy-driven fix-it list will get a response like, “We appreciate that Scott, but we have so much to get done on the product, we don’t have time to tweak things like that right now.” Never do you feel so put in your place when someone says that your job is “tweaking.”
The paradox of empathy is that while it drives us at a very deep level, and ultimately leads us to big, important insights, it usually starts small. The empathic process typically notices simple things like ineffective error messages, observed user workarounds, or overly complicated dialog boxes. Empathy starts with very modest steps. However, these small observations are the wedge that splits the log; it’s these initial insights, if you follow them far enough, that open up your mind and lead you to great products.
Building the right thing vs. building the thing right
Usability does not determine usefulness.
Register for the UX Design for Growth — Improving User Conversion training session with Laura Klein. In this online, interactive training workshop, Klein, author of “UX for Lean Startups,” will teach you to design for product growth.
I love it when companies test prototypes. Love love love it. But it makes me incredibly sad when they use prototype testing for the wrong thing.
First, let me give you my definition of “prototype testing.” I often build interactive, or semi-interactive, prototypes when designing a product. These prototypes are not actual products. They’re simulations of products. People who see the prototype can often click around them and perform some simple tasks, but they’re generally not hooked up to a real backend system.
“Well, what good is that?” you might reasonably ask. Excellent question. Interactive prototypes are incredibly useful for finding problems in usability testing settings. In a checkout flow, you might create a simple interactive prototype and watch four or five people go through the process (with test accounts) in order to find out if there were any parts of the flow they found confusing or hard to use.
It’s a great technique for any reasonably complicated interaction that you want to test before you spend a lot of time writing code. Interactive prototype testing can save you a ton of time because it helps you make sure that you’re building the product right before you spend a lot of time and money actually writing code.
However, the thing I see all the time is people using prototypes to try to validate that they’re building the right product. Stop it. Stop it right now.
Let me explain. The common pattern is that people go out and do some research on a problem (yay!) and then their next step is to build a prototype of their solution in order to show it to people and get feedback.
This is a wonderful thing to do. You should absolutely show your prototype to people in order to get feedback. You just shouldn’t expect feedback about whether or not anybody will actually buy or use your product. In other words, you can’t use a prototype to learn if you are building the right product.
Why not? Well, it has to do with the nature of doing qualitative research on a prototype.
Imagine that you ask somebody to look at your product. Maybe you stopped them on the street. Maybe they answered an ad on Craigslist. Maybe it’s a friend or a friend of a friend. You ask them a few questions about their life or job. Then you show them something that looks kind of like a product. They can click around and input some data. They can perform a few tasks. Then you ask them if they would use this product when it becomes available in a couple of months or weeks.
They will overwhelmingly say, “yes.” If they don’t say yes, they will say, “probably,” or, “no, but my cousin would use it.” You will get a huge number of false positives for all of the following reasons:
- People want to be polite and helpful.
- People dramatically overestimate their willingness to adopt new things.
- People are bad at predicting the future.
- People are bad at extrapolating real product behavior from an interactive prototype.
None of these problems come into play when you’re using a prototype to test for usability because usability testing is about evaluating facts. It answers questions like:
- Will a reasonable person be able to perform a specific task?
- Will a normal person get confused by the messaging?
- Am I building this product right?
Testing for usefulness, on the other hand, is about trying answer questions like:
- Will a lot of people buy my product at some uncertain point in the future?
- Is this product the best solution to a problem?
- Am I building the right product?
And these are simply not things you can answer with prototype testing.
But don’t worry. All hope is not lost. You can still test whether you’ve got the right solutions to problems before you build an entire product. You just need to validate in other ways. Important ways. Ways I’m not going to go into right now, but I covered a few of the key points in my talk at the Lean Startup Conference in 2013 though, and you can see a video of that here.
Public domain image on article and category pages via Wikimedia Commons.