Being a virtual company has it’s challenges – communicating, planning, collaborating, tracking, managing and delivering have many potential pitfalls. We wanted to take a moment to highlight some products that have been helping us to drive more efficiency in our virtual structure.
In recent months, Limina has been picking up the pace in collaborating with UX personnel in the field and delivering our services. This has been, in no small part, due to our use of collab-ware. We’ve recently migrated our intranet, client extranets and project collaboration space to OneHub workspaces. For the past 5 years, we’ve been using GoToMeeting to facilitate our internal project checkpoints, along with a host of user research activities and client presentations. And we’ve recently started using ClickTime as our user friendly time reporting product.
Other enablers we’re tinkering with in our lab include: Pidoco, iRise,and iMockups, to name a few. Add into the mix Skype, GoogleDocs, chat and mail clients and you’re well on your way!
We just thought we’d give a shout out to technology products that’ve been making deploying our user centered research and design services not only more efficient for a decentralized UX practice, but fun and easy! Our clients and field agents love how we’ve brought these products into our process and service delivery suite. And we couldn’t think of any better way to say: “We <3 These Great Products!”
-Jon
Onehub Workspaces
Customizable workspaces for online collaboration. Manage projects, share files and collaborate with others.
Some say Product Management; others believe it is a Software Development responsibility…
We believe that product usability is the responsibility of all departments and functions involved in the development process: Marketing, Sales, Software Development, QA, Help Desk and more.
In an ideal product and end user oriented organization, usability should be a core principle throughout all phases of the development cycle. This is a quick post to provide an overview of where various usability milestones should be injected into the definition, design, development and deployment of a given product or website.
Definition
In this early stage where requirements are being gathered, product management & marketing should take some time to better understand the target users, their environment and the subtleties of the interface requirements.
What are the gross categories of the target audience? This doesn’t necessarily fall simply into categories of user-role or demographic. More often than not, behavioral and environmental trends are what drive perceptions of whether something is usable, or useful. For example, people who work on their feet and are not necessarily at their desk for the full 8hrs of a given work day, will need larger visual cues for critical alerts or timely calls to action. This is typically the type of thing you will only catch if you conduct contextual interviews and user ethnography.
Design
During the design phase, it’s helpful to have your target audience and user types documented as personas. The persona documentation is a helpful reference tool for business and functional analysts charged with translating processes flows and functional requirements into system work-flow models and interface schematics.
More often than not, the phrase “That looks alright to me” is uttered among product managers and analysts without having a touchstone to vet the flows and schematics. Knowledge of the user personas, task models and use cases will always drive the design to a more solid state.
Even the best straw man work-flows and schematics can use some vetting – before moving into your development sprints, have the marketing and product team test out the design on paper with some sample users. Initial feedback on the mock-ups typically reveal insightful recommendations. Questions like “What would you expect to happen when you click here?” or “Why did you decide that’s what you needed to click?” will help you understand how they are perceiving the design and the information as you designed it.
Development
For whatever reason, UI designs often undergo a round of changes between leaving the hands of the UI designers and the final build. This is typical and usually can be attributed to technical, time or budgetary constraints.
Every now and then, changes are snuck in by engineers who have a feel for UI and have their own approach to design. For this reason, it’s helpful to document all of the flows and schematics, along with interactive states for all UI components. The documentation should be supplemented with the design rationale in order to maintain the integrity of the UI. This is particularly important for actionable design elements. If you don’t have a rationale for the design, you may want to rethink how it got into the schematic. As an added benefit, this helps to reducing developer’s time spent on interpreting designs and to remain focused on clean code.
Validation
Once development is complete and the product enters alpha/beta testing, A formal round of Usability Tests are essential and effective methods for benchmark data, validation of your designs and gauging readiness for market. Key concerns should be identified and addressed prior to release, or where appropriate they may be deferred and addressed during future product releases.
By keeping a fixed eye on the users and their interactions with the product, your organization will strengthen the vital bridge between usability issues and the software development view of the user interface.
Post Product Launch
Even after the product is released to market users will go through adoption and long-tail stages of use. Several rounds of usability testing will help gain the quantitative and qualitative user interaction feedback essential for success.
In gathering feedback from users and preparing for successful future product revisions and enhancements, your organization will ensure that the product has every opportunity to achieve the results required by your end users’ investment and trust.
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.
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!
m'
-n