81 posts categorized "development"

Friday, 04 February 2011

Thoughts on UX & Agile Integration

Came across Integrated Usability in Agile teams from the trenches via the Agile Experience Design group on Linked In and it contains some great tips for UX folk working in Agile teams for the first time.

I've been working in an Agile-ish shop for just about a year and I love it, having been seeking out opportunites to do so for a couple years prior to that. To me, the tenets of Agile made perfect sense to me as change is inevitable and Agile is about embracing and dealing with change rather than fighting against it. 

To add to Robin Dymond's list, here are some additional items that have helped me be Agile in my IxD work:

  • I've found being both the Product Owner and the IxD on projects helps me organize my IxD work as I have deep knowledge of what is most important to my customers and ensures I'm working from business priorities.
  • Also, it helps to have quick & easy access to all the people I service - business stakeholders, customers, and the development team. One of many reasons I have always preferred working for smaller companies.

  • Having breathing room between major development projects to take care of incremental improvements to existing applications allows me to increase my understanding of the business needs and the needs of the people using the software. This knowledge then feeds into the major development projects. During the gap between major projects I can also take time to develop conceptual models and high level interaction models so that I'm not as rushed when sprint 0 of a project hits. 

  • Using software (VersionOne) to organize the enormous backlog of requests across numerous software applications.

  • Lastly, working with a CTO that evangelizes both Agile and UX and has mentored me on taking a more systems engineering approach to my IxD work has been a very large part of the success I've had with Agile.

Thursday, 28 May 2009

Components, Patterns, and Frameworks! Oh My!

Jared Spool describes how components, patterns and frameworks can provide speed and efficiency to software development teams.

In our research, we've found that teams that build out a re-use strategy see tangible benefits: They are more likely to get a completed design sooner, with all the little nuances and details that make for a great experience. Their designs are more likely to meet users expectations by behaving consistently across the entire functionality. Plus, the teams iterate faster (always a good thing), giving them a chance to play with the design while it's still malleable.

  • Patterns: the design response to specific behaviors such as always using a calendar picker for selecting dates rather than drop-downs for month, day and year.
  • Components: the detailed implementation of the pattern; the code and styles to be used for the calendar picker.
  • Frameworks: groups of patterns and components. The date picker could be part of a larger framework for a personal profile.

Monday, 23 February 2009

Future Practice Interview: Bill Scott

Lou Rosenfeld interviews Bill Scott, Director of UI Engineering at Netflix, and discusses how designers and engineers can work together better.

Scott recommends constant communication, collaboration and a shared vocabulary. Lou also asked what engineers wish designers understood:

I spent a good deal of time thinking about this question when preparing this talk. In fact I pinged a number of people I highly respect in both design and engineering. After listening to hundreds of comments and reflecting on my own experience I boiled it down to five simple ideas that developers wish designers understood.

  1. The site is dynamic. Photoshop is static—the site is not. The site is dynamic in content, layout and interaction. It's too easy to forget all of the details that come about when users get involved. But engineers end up having to fill in the gap where the designer has not accounted for all of these dynamic concerns.

  2. Technology is critical. Web design without technology is just art. You must understand the magic that gets it on the site. Designers that "get" the unique challenges of getting their designs live can make smart choices up front and anticipate problems or even better arrive at more elegant solutions.

  3. Components are key. Developers think in terms of reuse. Designers often think in terms of new ideas. To be effective you must plan for the common elements and interactions as this will map into a better experience as well as a more efficient use of engineering time.

  4. Partnership is imperative. It's tempting to design and toss over the wall. But the real magic happens during collaboration. Communication and constant iterative engagement are key to fielding a great user experience.

  5. "Yes We Can!" Interface engineers have the power to say "yes" more than ever. And there are a lot of technology advances coming that if you are aware of as a designer you will enlarge your toolkit of tricks. Good interface engineers see problems as challenges and instead of trying to whittle your designs out of existence they will try to make it happen. Good engineers want to say "Yes".

Wednesday, 28 June 2006

High Accessibility is Effective SEO

Andy Hagans writes on why High Accessibility is Effective Search Engine Optimization:

On further reflection, this overlap makes sense. The goal of accessibility is to make web content accessible to as many people as possible, including those who experience that content under technical, physical, or other constraints. It may be useful to think of search engines as users with substantial constraints: they can’t read text in images, can’t interpret JavaScript or applets, and can’t “view” many other kinds of multimedia content. These are the types of problems that accessibility is supposed to solve in the first place.

He also demonstartes how using the Priority 1 checkpoints in the W3C Web Content Accessibility Guidelines.

Further down in the article he references Google's webmaster guidelines where the points parallel a W3C guideline.

Design and Content Guidelines:

  • Make a site with a clear hierarchy and text links. Every page should be reachable from at least one static text link.
  • Offer a site map to your users with links that point to the important parts of your site. If the site map is larger than 100 or so links, you may want to break the site map into separate pages.
  • Create a useful, information-rich site, and write pages that clearly and accurately describe your content.
  • Think about the words users would type to find your pages, and make sure that your site actually includes those words within it.
  • Try to use text instead of images to display important names, content, or links. The Google crawler doesn’t recognize text contained in images.
  • Make sure that your title and alt tags are descriptive and accurate. [...]

Monday, 27 March 2006

Web 3.0

Jeffrey Zeldman writes on the hype of Web 2.0; both the good:

Some small teams of sharp people—people who once, perhaps, worked for those with dimmer visions—are now following their own muses and designing smart web applications. Products like Flickr and Basecamp are fun and well-made and easy to use.

That may not sound like much. But ours is a medium in which, more often than not, big teams have slowly and expensively labored to produce overly complex web applications whose usability was near nil on behalf of clients with at best vague goals. The realization that small, self-directed teams powered by Pareto’s Principle can quickly create sleeker stuff that works better is not merely bracing but dynamic. As  100 garage bands sprang from every Velvet Underground record sold, so the realization that one small team can make good prompts 100 others to try.

The best and most famous of these new web products (i.e. the two I just mentioned) foster community and collaboration, offering new or improved modes of personal and business interaction. By virtue of their virtues, they own their categories, which is good for the creators, because they get paid.

It is also good for our industry, because the prospect of wealth inspires smart developers who once passively took orders to start thinking about usability and design, and to try to solve problems in a niche they can own. In so doing, some of them may create jobs and wealth. And even where the payday is smaller, these developers can raise the design and usability bar. This is good for everyone. If consumers can choose better applications that cost less or are free, then the web works better, and clients are more likely to request good (usable, well-designed) work instead of the usual  schlock.

... and the bad:

We pause but a moment to consider two AJAX-related headaches.

The first afflicts people who make websites. Wireframing AJAX is a bitch. The best our agency has come up with is the Chuck Jones approach: draw the key frames. Chuck Jones had an advantage: he knew what Bugs Bunny was going to do. We have to determine all the things a user might do, and wireframe the blessed moments of each possibility.

The second problem affects all who use an AJAX-powered site. If web signifiers and conventions are still in their infancy, then AJAX-related signifiers and conventions are in utero. I am still discovering features of Flickr. Not new features—old ones. You find some by clicking in empty white space. This is like reading the news by pouring ACME Invisible Ink Detector on all pieces of paper that cross your path until you find one that has words on it.

Thursday, 27 October 2005

"What is this site for?"

Greg Storey writes on the importance of developing a sound strategy for your web site. (Love the title of the article — "Never Get Involved in a Land War in Asia (or Build a Website for No Reason)")

When it’s finished, the strategy will outline the who, what, and why of the website.

As an example, the author created a strategy for the article:

To convince… ALA readers
to use… strategy to define the purpose of a website
instead of… ignoring it and moving right into production
because… strategy brings focus to the project and serves as a framework for all the components that make up a website (IA, copywriting, design, development, marketing, janitorial services, etc.).

Realign your site, not redesign

Cameron Moll talks about the continuing trend of incessant redesigning in an A List Apart article.

Like a kid in a candy store, we creatives redesign like it’s the new black. Why do we possess such an insatiable desire to refresh and remake? Why do we thrive on renewal? What tempts us to be seduced by the sway of renaissance?

And contrasts "The Redesigners" from "The Realigners":

Thus, the differences between Redesigners and Realigners might be summarized as follows: The desire to redesign is aesthetic-driven, while the desire to realign is purpose-driven. One approach seeks merely to refresh, the other aims to fully reposition and may or may not include a full refresh. (Note that by “reposition,” I mean strategy and not physical location or dimensions.)

Wednesday, 05 October 2005

Grid Systems

Mark Boulton wrote an excellent 5-part series on grid systems entitled "Five simple steps to designing grid systems."

  1. Subdividing ratios
  2. Ratios and complex grid systems
  3. Grid systems for web design: Part 1
  4. Grid systems for web design: Part 2 Fixed
  5. Grid systems for web design: Part 3 Fluid

Onion Grid

Khol Vinh from Behavior, describes the sixteen-column grid behind the recent redesign of The Onion.com.

The site will never display sixteen individual columns of content, of course, but dividing the page up so rigorously helped us in making logical decisions when placing items on the page — there’s always a column edge nearby with which to align an element, so fewer intuitive placement decisions must be made. This is the “rational” part of the term “rational grid,” and it’s exactly the intellectual part of this craft that gets lots of design geeks — like myself — all hot and bothered.

Thursday, 08 September 2005

Pullquotes

couple tips on creating pullquotes from css-d:

Pullquotes with CSS and Unobtrusive Script

With this tip from David Hucklesby:

I'd like to suggest using text quote marks in place of images. You can use entities (“ and ” for example) put them in a SPAN and style and float them. I find this more versatile than images, easier to style for print, and zoom with text size.

My Photo

My Photos

  • www.flickr.com
    carriejeberhardt's items Go to carriejeberhardt's photostream

More Places to Find Me

Flickr LinkedIn Other... Twitter

My Tribe

  • Interaction Design Association

    Interaction Design Association

Subscribe

Powered by TypePad Member since 07/2003