Jared is Founding Principal of User Interface Engineering. He's been working in the field of usability and design since 1978, before the term "usability" was ever associated with computers. Jared has guided the research agenda and built UIE into the largest research organization of its kind in the world.
Jared is a top-rated speaker at more than 20 conferences every year. He is also the conference chair and keynote speaker at the annual User Interface Conference, and is on the faculty of the Tufts University Gordon Institute.
In this week’s UIEtips, we share an article from Bruce McCarthy. In it, Bruce defines the product roadmap and offers twelve areas where organizations break down when developing roadmaps. Best of all, he shares ideas on how to put all twelve roadblocks in your rearview mirror.
A good roadmap inspires. It inspires buy-in from executives, inspires confidence from customers and salespeople, and inspires development teams to produce the groundbreaking products that drive significant growth.
A good roadmap keeps your organization on course toward its destination. Stating what you will do and when makes it easy to judge when you fall behind schedule or get detoured by good ideas that just don’t fit your strategic vision.
It’s not uncommon that an interaction for an app on a mobile device is completely different than a desktop. Could inline help be the answer to communicating the necessary action? It’s not so easy as that as Luke Wroblewski points out in this week’s UIEtips. You still have to surface the hidden interface.
A common way to provide relevant bits of guidance inside an application is through inline help. Inline help is positioned where it’s most useful in an interface and made visible by default so people don’t have to do anything to reveal it. This makes it an effective way to tell people how to use an interface. But what happens when those instructions vary by input type.
It’s not uncommon within organizations that web site content is treated differently and separately from the web site design process. Yet the users do not separate the two and see it as one experience. When the content and design process are not done hand-in-hand, poor user experiences is often the result. Today’s article focuses on this issue.
Tying together your content and design process is such an important issue that we’ve brought in Steph Hay to do a full day workshop on it at the UI19 Conference in Boston, October 27-29. Steph will show you how to map conversations as a first step to designing customer-centric user experiences.Learn more about Steph’s workshop.
Here’s an excerpt from the article:
It’s not news that the content is the important part of the design. For years, Karen McGrane has told us that working on the design without considering the content is like giving your best friend a beautifully wrapped empty box for their birthday. They’ll enjoy opening it, but will be sorely disappointed with the entirety results. And recently, Steph Hay reminded us that “content is the entire reason people come to the design in the first place.”
The new thinking is that content creation and management cannot be a separate endeavor from design creation and management. That we need to inseparably integrate the two, structurally and organizationally, to create great experiences.
I believe many people in our industry struggle with “design in the browser” simply because they aren’t fluent with the tools needed for working that way. I’ve heard many people say, “Happy accidents don’t happen in code like they do in PhotoShop.” I can testify that this is absolutely not true. Instead, I believe it’s about where you are the most fluent.
As we evaluate the best tools for the monumental task of problem solving in design, I keep coming back to the ideal of fluency as a solid principle on which to base the decision. You can’t write poetry in a language you don’t speak. Similarly, you can’t craft design using tools you’re not fluent with.
In the past few years, we’ve recognized the danger in jumping headfirst into full-comp design before we really understand the design direction. Other disciplines have recognized this for a long time-think mood boards in branding-and taken steps to ramp up their design effort. The goal here is to establish the basic building blocks we’ll use in the rest of the design process: things like color, type, texture, illustration style, photography treatment, iconography. Once these are established, the success rate for the rest of the process is greatly increased. There are a number of ways to do this on the web; let’s look at a few.
Get access to all 8 UX Immersion Mobile videos for just $23/month through All You Can Learn by UIE. Additionally, your subscription allows you to view any of the 170+ seminars and other conference recordings.
The UXIM recording topics and speakers:
Building Dynamic Systems from Atomic Elements
Doing Pocket Research to Learn About Your Users’ Lives
I remember seeing an architect who talked about his best projects. When he walked through the finished building for the first time, he said it felt completely familiar because it matched exactly what he’d imagined years before. His intention had made it all the way through the implementation process.
Seeing our designs rendered exactly as we imagined them is exciting. Yet it’s frustrating when our designs aren’t implemented the way we were thinking.
As we study what makes design teams successful, shared understanding keeps bubbling up to the top of our list. Teams that attain a shared understanding are far more likely to get a great design than those teams who fail to develop a common perception of the project’s goals and outcome.
In today’s UIEtips, Jared Spool explains how storytelling is the core of design communication. Here’s an excerpt from the article:
Knowing how to change the users’ behaviors is one thing. Knowing which behaviors to change is another.
There are often many approaches to improving a design. Everyone can think they are working towards a better overall experience, but if each team member chooses a different approach, the design becomes confusing and complex.
When we’re working on a team, getting the entire team to work together from the same approach becomes job one. Smaller teams (such as those with six or less folks) have always had an easier time of this than larger ones. This is because it’s more likely the smaller teams are checking in and talking to each other.
Fortunately, there’s help for larger teams. It comes in a technique that is as old as humanity – storytelling.
In today’s UIEtips, Dan Brown of EightShapes discusses the three ways in which people misunderstand collaboration. You’ll be much more successful encouraging collaboration with an understanding of these misconceptions.
Sometimes, people think of collaboration in very simple terms, ignoring the planning, structure, and organization it requires. There are three common misconceptions that oversimplify collaboration, as discussed next:
Throw smart people together. Suffice it to say that working with smart people is satisfying and challenging. But collaboration isn’t just about smarts. It’s about providing a framework for working together. Just as important as intelligence is a willingness to work within the framework.