Services Approach Clients Resources About Us Contact

Agile Usability – How we see it.

December 17th, 2009

We get a ton of hits on our Agile Approach page so I thought I’d take an opportunity to give some more background on our methods and share some of our experiences.  The Limina Team comes from a traditional Waterfall or Rational Unified Process software development background.  Our consulting history and practice methodology is an adaptation of best practices developed in-house by user experience professionals and collaborators who’s expertise run the full spectrum of user interface; research, analysis, strategy, management, interaction modeling, information architecture, design and development.  As a result, we have developed a suite of services that can be applied throughout the full span of the product development lifecycle.

As a practice, our methodology has been flexible enough to add value to every client engagement in our portfolio.  As our team engaged on increasingly more frequent Agile/SCRUM driven teams, a trend which began for us in 2006, we needed to make some adaptations to keep pace with rapid iterations.  The following is a rough breakdown of the adaptations we made by “activity”.

We tool a look at the activities and deliverables we execute in a more verbose and lengthy cycle and dissected each phase to  determine which tasks and deliverables dovetail with the Project, Incremental Release and Sprint cycles of an agile project life cycle. Each level invariably incorporates tasks and deliverables from the traditional Analysis, Definition, Design, Development phases.  Here’s what we came up with:

Product Cycle: Assuming 6-9 months.

Intense Observation and Analysis activity in the all important “Phase Zero” a period of three to six weeks.  In the absence of the waterfall lead time, this is the cycle where UX research seeks to identify the following in rank order:

  • Task / Activity Model
  • User Role Model
  • Business Stakeholder Goals
  • User Goals
  • Competitive Analysis

Release planning: “Iteration Zero”.

While rough concepts are being established to determine technical frameworks and baseline use cases, the UX team takes 2 weeks to elaborate on the primary storyboards to cover feature definitions in the first iteration.

The At this phase, requirement gaps have been identified, rudimentary user typologies have been identified, development road map has been established based on technical complexity, feasibility, business benefit and user benefit.  Relevant personas for the user stories and features are drafted, usage scenarios are  drilled down, the draft interaction model is established and the associated process flows and wire frames are generated.  This iterative cycle is a lather, rinse,and repeat.

Ideally after 2 weeks iteration zero kicks off user stories, wire frames and mockups and will be available for itteration one development work.

While UX team is cranking out user stories and related assets for iteration two, custom asset creation and spot UI reviews run in parallel in support of iteration one.

This  completes the lather, rinse, repeat cycle.

Meanwhile, persona assets, user stories and related assets are aggregated up for incremental release review.  Any usability or user experience hurdles are triaged and assessed for re-insertion into the iteration plan.  Instructive text, user help documentation are written and evaluated for release.

Benefits and Lessons Learned

As a seasoned UX practitioner, I know the value of getting the requirements right before writing a line of code and my initial reaction to agile development was harsh to say the least.  It’s just a temporary jolt.  Once you get in the swing of rapid iteration and continuous design, you barely miss lengthy requirements gathering and documentation.  The clear benefit is low upfront project spend and near term return on investment.  In traditional models, upfront costs on analysis, strategy, definition and design don’t immediately translate to rapid deployment.  And the upfront cost is significantly higher to account for  end to end specification prior to development.

In an agile team, the analysis, strategy and definition are more light weight and design an development run in parallel.  If high yielding business benefits are addressed in the early release, you will be seeing a return on the investment   earlier than you would have if you staggered the design and development in waterfall fashion.

One major lesson learned for Agile UX in practice:  It is absolutely critical to get one or two iterations ahead of the development team. One slip, and you lose any runway for giving yourself the time  necessary to construct successful solution to meet the needs of your users.

Happy Sprinting UXers

-Jon Fukuda

Copy Cat by Design

October 15th, 2009

A nice percentage of our web traffic comes to us, believe it or not, from Google images. As we started to analyze the traffic we found that our Agile Usability Model was one of our main attractions.

Agile Usability is clearly blowing up and becoming a much more efficient model for addressing continuous design and development, so it’s no surprise that this page in particular has piqued some interest. We had not, however, anticipated that our concept was something someone would lift almost to the letter.

A small IT and Development Outsourcing company, BMBO, decided that they liked the visual concept enough to take roughly 90% of the design and visual concepts intact, while altering (minimally) the content.

Joost van de Wijgerd, Founder and Advisor to BMBO, has yet to respond to our email which acknowledges the uncanny resemblance. There’s no telling if they’ll attribute the design (which you may note they ironically watermarked as their own) to Limina, but in the mean time… we’re flattered.

Social Intranet Survey

October 1st, 2009

Limina Social Intranet Survey

Recently, intranets and enterprise systems are being met with s host of new “social web” requirements. How are these new requirements bleeding into the corporate culture? How successfully are these requirements being integrated? What are the challenges, what are the risks and how do you define success?

Our study looks at internal company networks and how they are or are not employing social media as a means of increasing or aiding communication, collaboration, process management and productivity. Our initial responses are giving us a better idea of the importance of social media on the company intranet as well as where issues currently exist that might be preventing companies from making use of the technology.  We’re confident this will be a valuable report.

Our responses are coming from hundreds and potentially thousands of people at all levels of their organizations. We expect that this approach will give us a more accurate representation of the current conditions.

Survey participants will receive a pre-release version of the report when the results are compiled.  Take the survey!

The survey should only take a few minutes to complete. For all questions, there is a “n/a” (not applicable) answer if the question does not apply to you or your company.

About Limina

Our user experience research and design consultancy specializes in user research and complex information design which includes multi‐layered workflows and complex visualizations. We improve user effectiveness, make products easier to learn, operate, and more meaningful in their function.

If you have questions regarding this report and our research program, please contact Mimi Knowels (mknowles at limina-ao dot com).

Usability – Matters at the Core

September 10th, 2009

How to better incorporate customer feedback into your engineering driven product.

Limina is often faced with products that have been in the market for years with little to no professional user centered and UI design methodology applied. It’s typically apparent in the interface before delving into the history of development through issues including but, not limited to the following examples:

  • inconsistent UI patterning
  • obtuse, or in many cases, non-existent workflows where users are either left to their own devices to develop their own approach to the system or spend time in manuals or training
  • random color and graphic treatments with little or no usage rationale
  • core features and functions hidden in right click menus with no alternative access
  • extensive use of dialogs and workspace changes to complete primary tasks
  • random and inconsistent screen layout
  • chop-shop iconography, cut and pasted from other applications

Most of these issues can be attributed to an engineering driven culture where usability has not been a core part of the methodology. Sure, the code is clean, the feature works, QA and Unit Tests have passed with flying colors… but is it usable or useful from an end to end experience?

A typical engineering approach to incorporating customer feedback
As a stop-gap to implementing user centered design practices, we’ve heard: “We’re meeting with our customers regularly to hear what they need and we keep them happy by feeding these requirements directly to the engineers to implement.”

First of all, we applaud you for going directly to the users with your product and taking back their requests into the design… but this is a slippery slope.

Although you may know your users and even have some working for you, how well are you capturing their needs? Are you asking the right questions? Are your users able to articulate what they need? You may have voluminous user feedback, support call logs, or error log reports on file, but have you put the user data into a framework that generates an actionable set of UI enhancements?

Equally important; when you have captured their feedback, how do you use it? Without a clear definition or roadmap for incorporating the user feedback, your product is at risk of losing competitive ground. When a company has to spend additional revenue in extensive training sessions, help documentation, call centers and product revisions, the margin of return on investment can take a massive beating.

Here are some activities to help you to incorporate user feedback into your agile development practice:

1) Give the feedback some context – What were users doing or attempting to do when they encountered the issue, and what are their roles? Usability specialists conduct a set of contextual inquiries to interview and observe users as they are performing various tasks in the context of their workplace to determine both system and non-system based activities, documents, and tools that are used to complete their tasks.

2) Quantify and qualify the user data – Where do you see common issues reaching a critical mass? Which are the exceptions and how do you prioritize them? What issues constitute a completely new set of features and possibly a new product?

3) Organize it – Once you have synthesized and prioritized the issues, determine their relationship not only to the system, but also to each other. Which comments are related and which ones are specific to a given task or feature?

The result is a set of researched usability issues that can be organized into enhancements prioritized by issue, prevalence, technical complexity, business, and user benefit.

Such a framework should be employed when embarking on a product definition or enhancement process. It allows parties from marketing, product management, and engineering to uncover the root of software design issues that challenge usability, and ultimately to gain a deeper understanding of their users. Product managers and engineers who gather and process user feedback assist their company by developing the right products and tools for their customers.

This post includes an excerpt from Limina’s white paper “Nine Ways to Improve Software Usability and Increase Market Share“.

Skipping this step leads to an iterative path of organically distorting the original design of the system and frankin-hacking patches and appendages to the product to the point where rebuilding from scratch is easier than overhauling the UI when your users start running to your competitors.


There are a great many development teams using agile methods, SCRUMing it out, getting the features out the door to see what sticks. In many ways, this is a helpful model to beat the first-to-market and innovation clocks, but if the net result is revisiting the feature again and again or playing “pass the trouble ticket” from developer to developer as the feature enhancement is punted to the next iterations for months… something isn’t working.

We are all for engineering driven product teams. In most cases, massive leaps in technical innovation are paved by developer teams and individuals unhindered by business and user requirements. But we’re talking about products in the market that have ROI, user adoption, marketability, competitiveness and other business considerations to name a few.

There’s something to be said for dealing with the cost up-front; for taking the time to build a sustainable product whether in its initial incarnation or when producing the next generation of its kind, because the hidden cost of maintenance, marketing and training can work against you in the long run.

Give us your thoughts and share your experiences with us and our readers!