September 24, 2007
Designers Wanted.
Adobe Consulting Worldwide (AC) is looking for top notch Experience Designers, Architects and Design Leads to design next-generation, rich client applications for strategic third-party engagements.
Here is a list of the current openings:
* Design Lead - New York
* Experience Architects - New York
* Experience Designers - New York
* Sr. Experience Architects - San Francisco
* Experience Designers - San Francisco
* Experience Designers - Italy, Germany, UK, and France
Your resume and portfolio must demonstrate a broad depth of experience on projects related to application and user-interface development. You need to be part interaction designer, part information architect, part business analyst, part mentor, part evangelist and all about user experience.
Think you have the skills? Contact our recruiter Julia Margherita (juliam@adobe.com)
Posted by Simon Smith at 4:33 PM | Comments (1)
May 9, 2007
Design for the other 90%
The name of this site is "User Experience Hub" and is, generally, focused on the details and implementation of software interface design. However, "user experience" can thought of in a much broader way. Though the examples on the following URLs are not software interface design examples, they do reinforce the value of design and of fundamental design principles.
Many of our projects may not have the immediate, life-saving benefit of the LifeStraw, but the same principles that guided its development should guide every software interface design we do.
- Understand the "point"
- Understand the context
- Help people
Check out the Cooper-Hewitt "Design for the other 90%" and the BusinessWeek article about it for more information and inspiration.
When we go and design our next business dashboard, or data entry interface, it may not seem to have the same gravitas as some the products featured, but we should approach these seemingly banal project with the same rigor and thoughtfulness. In the end, all our interfaces connect with people. And people deserve interfaces that make sense in what they are trying to achieve, make sense in the context they are doing it and should be helpful.
Those are pretty simple ideas that can have a big effect.
Posted by at 5:09 PM | Comments (2)
May 3, 2007
The Role of User-Experience Design in RIAs
Walking home the other day I ran into an old high school classmate who I hadn't seen in over 12 years. We did the obligatory catching up, and of course she asked what I did for work. What followed was a typical scenario. I explained I was a user-experience consultant for Adobe, which was followed by a blank stare.
"You know, Flash" ... Another blank stare.
The fact of the matter is a lot of very bright people use our technology every day, whether it be Flash Video, Flash Applications, PDF, or consume a product that has been designed by Adobe technology, and have no idea that they are using Adobe technology.
In that light, I've found that the recent conversations back-and-forth about Silverlight and Flex/Flash have been almost exclusively developer-focused ... a sort of, "lets stack our tech-specs and stats up against yours"... and what seems to be getting lost in the conversation is the "User". The point of this post is not to go down the whole Silverlight / Flash road, but I will say that most, if not all of your users will have no idea whether your app was built in Flex, Silverlight, or AJAX, or event know what those words mean. They will have an experience with your application, and if its a bad experience, regardless of how great the technology is, they won't come back.
One of the great things about working for Adobe, and with Adobe Technology is that Adobe has a decades-long history when it comes to user-experience design, and been at the forefront of helping to define good user experiences, and enabling others to define great user experiences. However, and this may sound like heresy as an Adobe employee, Adobe does not have a monopoly on user-experience design. Adobe doesn't "own" user-experience. User experience belongs to the user.
Another great experience that I've had working in Flex with some of the best and brightest Flex developers is that I have never designed anything that our developers couldn't build, and I've designed some pretty wild stuff. The response we always get is, "we can build anything, some things just take longer than others". I love the freedom that I get to design and focus on the user, and not be constrained by the technology.
So, my point of this post is the following.
If you're going to build a rich internet application, whatever technology you use, do the following:
Hire a great User Experience designer: Flex makes it easier to develop great experiences, but you still need designer to determine what the most appropriate experience is.
Give designer and developer opinions equal weight: Consider the role of the designer as on par with your developer. Developers need designers, and designers need developers.
UX Design is about usability AND polish: Users' connections to an experience is more than just how easy it was to complete a task. It's also about an emotional connection. It's about how fun the experience was, and how visually engaging it was.
Give designers the freedom to go beyond out-of-the-box: Flex includes a good set of out-of-the-box components that make it easy to develop applications. However, don't limit your designers to that component set. Let them explore and find the best solution possible. And then evaluate how expensive it would be to implement that solution against the user needs.
Here's to great user experiences.
Posted by Peter Baird at 12:25 PM | Comments (5)
October 27, 2006
Designing More Usable Applications with Flex UI Capabilities
I wanted to thank everyone for attending Albert and I's presentation. We both really enjoyed the feedback and response that we received (Especially when Albert dropped the F*Bomb).
So... Over the next week or so I will make sure that we post all of the files from our presentation. Including the source files from the Flash based "Paper Prototype" and the Flex Project. In the meantime, if you have anything encouraging to say about our preso or have questions, please feel free to drop us a comment or a note.
Thanks Again!
~
Brett Rampata
Oh... one more thing. What happened in Vegas stays in Vegas. ;)
Posted by Brett Rampata at 5:10 PM | Comments (6)
July 21, 2006
Yahoo Maps QuickTip: Measure Mileage for an Exercise Route
Okay, so this is admittedly off-topic from the usual Adobe Consulting fare, but I recently discovered a nice feature of Yahoo Maps Beta that's a bit hidden that may be of interest to those who exercise and like to measure mileage of new routes.
For those who know me and have seen me in person, you might be surprised by the fact that I like to run - when I get the time, that is. Well, I also like to know how far I'm going when I run so that I can, say, decide to go out on a 3 mile run. For all the mapping websites out there (Mapquest, Google Maps, Yahoo Maps Classic), none of them had a way to draw a line on the map and get a mileage for that line. The best I could do was get directions and the mileage based on driving directions. Of course that's fine and dandy if you want to run on a highway. But, what if I want to run along some back roads? With every new Mapping RIA that comes out, how I wish for a simple measuring tape tool. (Okay, I'll confess as a User-Experience guy, I know that this doesn't exactly fall within the 80% usage rule here).
Enter Yahoo Maps ... you know, the Flex version. With the API I knew it'd be possible to create the tool myself, and I've thought about it off and on, but, I'm not THAT desparate to find new running routes. But, then recently I discovered something about Yahoo Maps. Right click and you get a "Drive to here..." menu option. Combine that with multi-point directions and, while it's still driving, I can define my route, and not have Yahoo tell me the quickest way to drive there. Starting from my home, I can right click a a few blocks down the road, and then again, and again, following the route I want to run, and get a total mileage count for my planned run (or bike, or walk, or whatever).
Okay, it's not perfect, since it's going to account for one-way roads, and will only go places a car can drive, but until some enterprising developer out there creates the measuring tape tool for Yahoo Maps (or any other Mapping RIA... ESRI maybe?), it's the best I can do.
Another possible use of the multi-right-click-trip-planner (I think I'll have to trademark that term): Anyone inspired by the recent Pixar release Cars who would like to plan a trip... not necessarily the fastest way there, but the scenic route, can get those directions and a time estimate of how long it will take, without being told by the application "No you really want to take the Highway... it's the fastest way".
If anyone does build a real measuring tape tool, let us all know.
Posted by Peter Baird at 12:23 PM | Comments (7)
July 29, 2005
Gestural Navigation in Flex
One of the great things about Flex is the "mouseOver" event that pretty much any component, including containers, has available. What this means is that we can trigger almost any event without requiring a mouse click. Why and when would you want to do such a thing? Imagine, for example, a list with details, as shown in the flex application below.
In this example, we've got hypothetically limited real estate, where when our focus is on the list, we'd like to see as much of the options as possible, but while our focus is on the details, we'd like to read and view all the details as possible. The different mouse interactions in a user interface that could be used, in order of level of increasing level of effort are:
1. mouseover (rollover button, highlight)
2. click (button)
3. click and hold (scroll arrows)
4. click and drag (scrollbar thumbs, dividers)
Given that this is a list of items, these interactions would be repetitive as the user reads details for each action. We, therefore, would want to minimize the level of effort, and this mouseover example would be an appropriate way to do that.
Why wouldn't you want to use a gestural approach to events? There are a couple of reasons you wouldn't want to use a gestural approach. First, if everything is gestural, there's the risk of many things bouncing around the screen, possibly becoming distracting. The second, larger issue, is one of intention and user expectation. A user click usually signals the users intent to an action or an event. You certainly would not want to trigger an event on rollover that the user did not intend to do. The types of changes that might be appropriate on rollover are subtle state changes. The user should not loose anything from the view without their intent. So, for example, a change of visibility in a viewstack would be less appropriate on rollover.
Finally, a consideration. The size of the target area for a mouseOver action should be larger that the typical target for a click, as it requires more precision. Hover requires a full stop and wait, while click can be a "drive-by" so to speak. So to make hover more accurate, it helps to make the target area larger. If a user simply wants to drive through a list and view details. Using the arrow keys is also very powerful.
To see the source code for the above example, right click and select "view source code".
Posted by Peter Baird at 7:34 AM | Comments (10)
July 27, 2005
World's first intelligent shoe
This is a nice step into the idea of configuring your digital environment. If only I could burn 300 calories while running through here. Kudos!
If anyone knows who designed this experience, I would love to know.
Posted by brampata at 3:28 PM | Comments (1)