Matt Friedel, of jam-mobile.com presented some good business background on the mobile market. His presentation Mobile Business: Strategy and ROI contained some nice stats on its ramp up over the past decade and forecasts for future trends. One of his main points was that you should look at the platforms of your particular user community when considering platforms and devices to target. Even though iOS and Android may be leading the market, your app may be targeted to an industry that mostly loyal Blackberry users. Once again, you need to get to know your users.
I also attended fellow UX guru, Gretchen Thomas’ presentation Mobile Design is for Mobile Users. It was a good primer to get people thinking about the contexts in which mobile users are interacting with the apps and sites that the audience is wanting to build. Like Matt, there was an emphasis on beginning with a mobile vision and strategy rather than modifying your current website to fit in a smaller format. I loved the fictional example she walked us through illustrating her point “Mob Buddy for Angry Townspeople”.
During the Q&A after Gretchen’s presentation, someone asked how she would approach Responsive Design. Her response was a traditional position that design should not be limited by implementation considerations. On this point, I disagree. As a matter of fact, I think that this approach is unattainable and also the main reason that designers encounter so much friction.
My theory is that a long time ago some designers had a difficult time coming up with creative web designs because they couldn’t think beyond pre-CSS HTML table layouts. So they were encouraged to sketch and design in Photoshop and think about the implementation later. That was back when the web was new. There were two major browsers and most websites were static. Today, interfaces are highly dynamic and computing is ubiquitous. To get a product to market quickly, designers need to collaborate with developers in order to get to the best design as fast as possible.
Designers need to understand the medium in which their designs will be built and the technical environment in which they coexist. How else can we create designs that are efficient and take advantage of the interface capabilities?If designers adapted to become better team members and let go of our hero designer egos, we would all make better products faster.
Several weeks ago, I had the opportunity to talk to Rob Keefer of Pomiet about his experiences with Agile UX. Rob shared several techniques that he’s had success with over the years, including the Sprint Ahead/Behind approach. Several others I’ve talked to have used this as well.
For those of you who haven’t heard of this before, here’s how it goes: You start with a sprint zero which gives Design time to get out ahead of development. As development gets started setting up environments and infrastructure, design continues to craft design documents that can be handed off to development in a subsequent sprint.
After a feature has been developed, design comes back around and performs usability testing and iterate. The trick is that in sprint 2, you will be designing for sprint 3, testing what was developed in sprint 1, as well as working with development as they build what you designed in sprint 1. Oh, and iterating the design in your free time.
Perfectionism is a common trait among user experience designers. We are known for paying attention to the small details that make a big difference to users. Like QA testers, UX designers look for the holes in the design, catch the dropped balls and find where the approach falls down. Valuable skills to have on any team. But like any good thing, this talent can become an Achilles Heel. Perfectionism stalls the designer in endless meetings and revisions.
Carefully crafting every detail takes a lot of time. Adapting to change quickly generally translates to late nights redrafting wireframes to keep a team of developers from waiting, idle. If a change to the security requirements is made, using email addresses instead of an 8 character user name for instance, you’ll have to reexamine the entire experience looking for those ‘gotchas’ and reworking what you spent so much time creating. So designers take measures to protect themselves from change.
Here’s reality. Design happens in the same Catch-22 environment as development. You will never know everything you need to know before you start. Doesn’t matter how long you spend in discovery or how many business analysts you throw at the project. The digital world is an ever changing environment where business needs shift quickly, the technical landscape evolves, and we never stop learning about our users. As we design and build, we apply the knowledge that we have, and discover new things along the way. No one should be expected to ‘get it right the first time’.