A Bias for Making

Today’s UIEtips article looks at the communication process designers and developers follow to bring designs to life. From the waterfall approach to an Agile method, the common goal is creating, building, and executing better designs. If you or your team struggles with communicating design objectives and process with developers and other key players, then you’ll want join us for Ben Callahan’s full-day workshop on workflow on responsive web design projects at UXIM April 7-9 in Denver, CO. Here’s an excerpt from the article: Step into the Wayback Machine, Sherman, and set the dial to 1994. You’ll find me in a conference room, explaining to a room of developers and product owners (back then, we called product owners either product managers or business analysts) how we would design their new product in less than a week. The expression on their faces would be one of OMG! This dude is insane. (Though, “OMG” or “dude” wouldn’t be common parlance for at least another half decade). We look at paper prototyping now and we think how quaint. Yet, back in 1994, it was a radical departure from established practice. In those olden days, design wasn’t done the way it is today. Read the article A Bias for Making. Does your team have a bias for making? Tell us about it...

UIEtips: Designs and deliverables are haikus, not epic poems

In today’s UIEtips, we’re publishing an excerpt from the UXmatters article “Developing UX Agility: Letting Go of Perfection” by Carissa Demetris, Chris Farnum, Joanna Markel, and Serena Rosenhan. In it, Chris Farnum talks about design deliverables and their role in an incremental approach to your design. If you want to hear more about Chris’ thinking on design deliverables join us for our January 30 virtual seminar Choosing the Right Wireframe Strategy for Your Project. Here’s an excerpt from the article: Once you have a firm grasp of the goals for a project and the functionality you need to design, the next steps for many UX professionals are creating user stories, wireframes, and prototypes. To kick off design, we often brainstorm and sketch. Often, cutting edge Web sites and a desire to meet or exceed competitors fuel our ideas in part. While you are in brainstorm mode, it’s certainly a good idea to sketch out a full user experience, complete with all the latest bells and whistles that would delight users and impress stakeholders. But when you begin to craft a user experience for the initial stories that you’ll deliver to your Development team for implementation, you’ll need to be a strict editor and include only the core user interface elements. Limiting scope in this way can be challenging when you are used to waterfall approach, in which you may have only one chance to document all of the user interface elements you think your design should include. Read the article Designs and Deliverables are Haikus, Not Epic Poems. How does your team limit project scope in the early design stages? Tell us about it...

Websockets and Why Designers Should Learn To Code

HTML5 has an awesome feature that’s now gaining attention from designers: Websockets. It’s a way to create a persistent communication channel between the client and a server, without using page refreshes or the asynchronous mechanics behind AJAX. Think much faster communications, because it’s not establishing a new connection for each round trip. Look at this cool Racer demo from Google, showing race cars racing across multiple devices, with no noticeable lag when the cars jump from one device to the next. Imagine moving messaging, data, or anything else at that speed. Real time updated stock prices, auction bids, or other fast-changing data. The limit is your imagination. Here’s the deal though: because it’s new, each browser implementation is somewhat idiosyncratic. The Racer demo works in Chrome, but may not work elsewhere. Making websockets work can be finicky. It won’t always be that way — the browsers will eventually fall into line. But for now, it’s a difficult thing to get it all to work. Here we are with a great, powerful tool. If we want to take advantage of it, we need to dive in and start playing. We need to see what it can do and what it can’t. We need to learn it like an artist learns their paintbrush, paint, and canvas. Websockets are just one reason why smart designers are taking the plunge and learning to code. With some simple coding skills, these designers can start playing with websockets and see what they are all about. They can work up simple demos and prototypes to test out ideas. They can get their coworkers excited about exploring...

UIEtips: Design is the Rendering of Intent

In this week’s TIPS, I’ll begin explaining design as “the rendering of intent.” Simply put, this is when the designer imagines an outcome and puts forth activities to make that outcome real. Here’s an excerpt from the article: What if the team had approached the design with a different intention? What if they had intended that users would get through the sign-up process without ever seeing an error message? Designer extraordinaire, Robert Fabricant once said, “Behavior is the medium of design.” When we encounter a user’s behavior that isn’t what we’ve intended, we change the design until we see what we want. An implication of this definition for design is how it changes our notion of who is a designer. Read the article Design is the Rendering of Intent. How do you assure your design process is a way to come to a single intention? Tell us about it...

UIEtips: Designing for Breakpoints

In today’s UIEtips, we offer an article printed earlier this year on A List Apart – Designing for Breakpoints by Stephen Hay (reprinted with the permission of A List Apart, the author, and the publisher). It’s an excerpt from Chapter 7 of his book, Responsive Design Workflow, available from New Riders. If your team struggles with how to design responsively, then you’ll want to hear Stephen’s practical approach to improving your responsive web design workflow during his December 12 virtual seminar on Responsive Web Design Workflows. Here’s an excerpt from the article: When thinking about major breakpoints, remember to think about device classes. If you’re thinking about smartphones, tablets, laptops/desktops, TVs, and game consoles, for example, you’re heading in the right direction. If you’re thinking in terms of brand names and specific operating systems, you’re on the wrong track. The idea is to think in terms of general device classifications and, sometimes, device capabilities. Capabilities are more important when designing web applications, since you should be thinking about what screens will look like both with and without any particular capability. Read the article Designing for Breakpoints. What are your strategies for designing breakpoints? Tell us about it...