Scaling User Experience – Keystone projects

When I talk about Red Hat and the growth we’ve had in the User Experience Design (UXD) team over the past few years, I am often asked how we got buy-in from the organization to grow so rapidly.  Selling the value of user experience when all areas of the business are feeling under resourced can be challenging, but we were successful through a few key objectives that I think would apply to many other organizations who are looking to build out their user experience teams.  The first of these objectives was identifying and executing on a keystone project.

The user experience team at Red Hat had one initial keystone project that brought the capabilities of the team to the forefront of organizational focus.  A keystone is a central stone at the summit of an arch, locking the whole together.  Without the keystone, the arch can’t be built.  We often also see keystones as beautiful architectural objects even after they have served their purpose to help build the arch.

Our keystone project was to show the time-to-trial for our product compared to our competitor’s products.  This was a keystone project because it had the following attributes:

  • It touched a central objective of many business units and leaders across the company – to make it easier to access our products
  • It brought together all the disciplines we currently had on the UXD team to accomplish this project
  • It’s output was highly visual and could be shown and referred back to easily by anyone

For the output of this project, the UXD team created ‘scrolls’ containing printouts of each user flow for our product vs. our competitive products.  The UXD Leadership brought these physical scrolls to a few key leadership meetings and were able to show the competitor’s flows (could easily place on the table) vs. our flow (the scroll would roll down the whole conference table).  This theatrical presentation of the data, along with the capability to provide digital copies of these flows to executives around the company, was highly impactful and showed the problem that Red Hat had in front of them without question.

The team was immediately given responsibility and access to the organization in a new way.  We built virtual teams across the business units to make improvements to this flow.  We identified web pages, documentation, quality assurance changes we could make improvements to.  We showed the scroll “shrinking”.  At the same time, we initiated a few key projects on the product UIs themselves to begin to show other ways we could impact and influence the company.  This keystone project started a cascade of activities that continued to fuel growth as executives across the company saw the impact we could have to change things from “status quo” to “innovative design outcomes”.




UXD Levels of Engagement

I often find that I need to discuss the different ways we are engaging with teams with stakeholders.  As a central UXD organization in Red Hat, we have to prioritize which areas we focus our attention on, making sure we are spending our UX resources in the right way at the right time.  We want to build long term relationships and knowledge in certain technologies and teams, while also weighing business objectives and strategic investment as things change over the years.

One tool I have been using to talk about our investment in UXD on different projects is a UXD Levels of Engagement diagram.  I start by showing and explaining the different levels of engagement we could have with a project.

UXD Levels of Engagement

UXD Levels of Engagement

We have defined 5 levels of Engagement:

  1. Strategic User Experience Design (UXD) and UI Development – Full UX workflow including research, interaction and visual design iterations, full js implementation, and final usability and code reviews. Final approval will depend on a review with users or usability testing. Architecture and implementation will be driven by UXD team’s front end UI developers.
  2. Strategic User Experience Design (UXD) – UX will follow the full UX workflow including research, interaction and visual design iterations, html/css, js implementation support, and final usability and code reviews. Final approval will depend on a review with users or usability testing.
  3. User Experience Design (UXD) – UX will use previously gathered research to provide initial wireframe and/or visual design with iteration based on reviews with project team. Limited number of design iterations, limited implementation support, but we will maintain final usability and html/css reviews.
  4. User Experience Design (UXD) Consult – UX will review design concepts and implementation. UX will be available to offer input. UX guidance will be limited due to the lack of integrated involvement with the project.
  5. User Experience Design (UXD) Best Effort – No planned UX input. UX assistance can be requested for occasional questions. UX guidance will be limited due to the lack of integrated involvement with the project.

Understanding our 5 levels required understanding the history of our team and how we’ve grown it.  UI Development is still a newer and growing discipline in our team, and allows for us to more quickly and accurately implement our designs to spec.  Other companies might come from a different background where UI development is not as strategic as it is for our team, so changing the definitions towards your unique situation makes sense.

Regardless of definitions, I would suggest maintaining a difference between those projects that require more fine-grained UX inclusion in the initiation of the project (strategic UX means you should be influencing the direction of the project during conceptual phases) and the conclusion of work (ensuring implementation meets user needs and expectations) to those that might get cursory direction from UX to ensure they appear professional, but will not necessarily will ensure they are great experiences.  You can also show levels that you can’t actually achieve today, highlighting the types of resourcing and disciplines needed to do strategic UXD in a way that cannot be achieved currently.

This leveling than can then be mapped against the areas of the portfolio, or even areas of a single project, to show how UX resources are being spent in the organization.  This should be reviewed as often as planning is done for the portfolio or projects with decision makers to evaluate how UX resources should be allocated alongside any changes in the business strategy.


Levels applied to projects - a column for project name, level, and link to project plan

Levels applied to projects


From this document, you could link to project plans or project dashboards that track more details for stakeholders in an ongoing basis.  You can see how we’re capturing more details about projects, their monthly status, and their prioritization in my post on project prioritization.

UX Project Prioritization

Now that I’ve been at Red Hat for nearly 5 years, I’ve built a lot of relationships with teams and individuals across the organization.  As a UX leader in an organization, once you have established these relationships and educated those around you with what UX can achieve, the inevitable next problem is prioritization of all the incoming requests that suddenly start to appear.

The most common designer prioritization mistakes

Priority by interest

I’ve seen many designers default to this.  They find things that are best defined, and seem most interesting, to spend their time on because they feel more effective doing this, and there is the most immediate reward (I enjoy it, I see quick results, people see my design prowess quickly, I add to my portfolio, etc.).

The problem with this strategy is that over time, you’ll start to realize that most of the time, following this strategy means that you are having the least impact on the organization or product.  These projects usually fall into two main categories:

  1. Projects that are well defined because they are small and aren’t challenging the limits of what we can offer our users. They often don’t result in great work or change.  “Oh, I’ll just keep working on these icons until someone can tell me what that next version of the product really is supposed to be, then I’ll work on designing it.”  No!  Go talk to people and use design to suss out the possibilities of what the next version of that product could be – it will further your career far more than those extra icons in your portfolio will!
  2. Projects that are interesting from a designers point of view because they allow for creative freedom through visualization as they are described, but as they are described usually doesn’t consider reality, and they often result in designs that never are fully implemented because they didn’t have the right support behind them.

Priority by the loudest/most connected person

This can be a hard one to handle.  The loudest voice, or the most connected voice, sometimes seems to appear to “win” in the priority argument just so that you can get that monkey off of your back.  These can be some of the most unhealthy projects for UX teams as team members recognize that they’re working on something that doesn’t matter in grand scheme of UX work for the company, and get frustrated or despondent about their work.  Sometimes these are unavoidable, but by building out a regular review system as described below, you can ensure that these projects are a rare exception rather than the norm.

Building a better priority system

Identify a board of reviewers

Find the stakeholders that matter in your organization.  Build a way to talk to them about priorities.  As a UX design lead, this has almost never been just my manager as the only stakeholder involved to determine my priorities.  It often involves someone from Product Management, Engineering Management, UX Management, and maybe other key stakeholders.

Establish a cadence of status and project review

Determine a cadence you can meet with those stakeholders, and figure out a way to report out your continuous status to this group inside and outside of those meetings.  At Red Hat, we began establishing UX Status dashboards to help show the projects and their status.  We recognized that sometimes UX “priority” is not equivalent to company “priority”.  Some products might have high visibility user experience work that is higher priority for UX than the product that makes the most revenue, or has the most focus for future viability in the market.  Having these in depth discussions about why a project might be high priority for UX when it is lower priority from a business standpoint are the key types of discussions you want from these sessions.


example project dashboard for priority discussions

Example project dashboard for priority discussions


After running these sessions for about a year, we have refined the dashboards and had much richer conversations with our stakeholders.  These conversations have led to more funding for UX as well as a deeper understanding from the key stakeholders across the organization about what UX can offer, how it will impact their goals, and how we do our work in relationship with their teams.

Going from request to requirements

User experience practitioners often end up needing to disentangle the web of asks and turn those into solid requirements that are actionable.  Requests typically start quite broad when working with a team that doesn’t have experience with UX designers.  It then falls on us as UX experts to help tease apart the real goals, and solidify them as agreed upon requirements and use cases.  In the following example, I’ll walk through this process as I recently did it for JBoss Developer Studio’s Central Page, a welcome page on our version of the Eclipse IDE for JBoss Developers.


The request

As shown in the JIRA JBIDE-18813, the original requirements were stated as follows.

[JBoss Developer Studio] Central Page requires new capabilities :

  • needs more customization (display content depending on user preferences)
  • needs to scale with JBDS-IS, Fuse content
  • access to more examples, with filtering capabilities


Gathering more information

We know that we’re working with JBoss developers for this functionality, but there could be some different personas who require different experiences from this functionality based on their level of experience with JBoss products.  I started by identifying the main goals that users might be needing when they open their IDE and see JBoss Central.  This information was gathered through discussions with JBoss developers, past experience with the products, and a SME (subject matter expert) who could talk towards JBoss Developer use cases.


We then had a meet-up with the team to discuss these and the original requirements.  From this discussion, we agreed on the user flows and generally agreed that customization was a requirement only because you could not see a variety of content in the current Central Page design – so if the new design addressed this in another way customization might not be necessary.


Wireframing for further discussion

Once the team had some general discussion about the user needs and requirements, I felt that putting some wireframe concepts together to further focus the discussion would be the correct next step.  The initial round of wireframes had a variety of directional choices for the team to select from, allowing further discussion about the goals, users, and requirements at a more detailed level.

Concept A

Concept B

Concept C

Concept D

Concept E

From these design concepts, it came to light that the “non-written” requirements that the team was interested in was a modern, simple welcome page.  They wanted easy entry for beginner and experienced users without as much visual clutter as they had in the past, and design option C fit the bill for them.   With discussion of a few small modifications, we were then able to move forward with Design C as the path for high fidelity designs and HTML/CSS creation.





Where should UX sit in the org?

Should UX sit in engineering, product management, marketing, under a special design organization, or somewhere else? There are advantages and disadvantages to each.  A few weeks ago I attended a great UX managers symposium run by Sarah Bloomer.  One of the topics discussed during this day by several of the attendees was around where they belonged in the organization in order to make the biggest impact that UX could make.  I think this question is often asked, and everyone wants the silver bullet answer.  Of course, as we love to say in UX, it depends!

Understanding your organization & your impact

The first part of the answer really is around understanding your organization.  Which division has the most pull and impact on company direction?  Where are there strategic players in the organization that you can align your UX team with in order to drive design and user centric strategies into the company?  What are the overall company goals for the next year, or next 5 years, that UX contributes towards?

Another factor to consider at this point is where you are in your UX maturity.  Using Neilson Norman’s Corporate UX Maturity Model, where are you?  If you are in 1 – 4, working in engineering might be more advantages because you can align UX people with development teams to create small wins to show the value of UX.  If you’re in 4 – 8, product management or a special design organization might allow you to be part of the strategic discussions that drive product direction before it gets handed to engineering.

Here at Red Hat, User Experience sits in the engineering organization.  UX is still a newcomer to the scene here, and the organization overall is tilt towards engineering-centric strategy.  Having UX with the engineering powerhouses allows UX to be part of the right discussions for strategic programs.  This means that for some products, UX doesn’t have a great tie with the product management and marketing teams.  For Middleware, I sit with the product management and marketing team and create that tie so that UX, Engineering, Product Management, and Marketing are all aligned towards our strategic directions.  This hybrid approach for an organization that historically has had some silos between engineering and product management and marketing has created some synergy that allows both angles to be addressed.

General advantages and disadvantages of each vantage point

There are some advantages and disadvantages that I have seen with working in different group locations that are fairly universal.  Understanding these might help you tailor your plan so that you make the right impact.

UX in Engineering

  • Participate in agile or other development process for the real work
  • Understand how the product works in detail and work side-by-side with the engineers who can enact change
  • Often handed requirements from product management without opportunity to influence them
  • Sometimes can get too mired down in the detail to understand how to make more strategic, significant changes to the product that would greatly impact the overall UX

UX in Product Management

  • Seat at the table for strategic, longer term discussions of product direction
  • Closer contact with customer needs and direction
  • Usually more connection with the rest of the business (Support, Marketing, Sales, etc)
  • Might not be closely aligned with engineering to accomplish product goals.  Designs might be treated as “concepts” more than “specs”.
  • Have to learn how to step out of strategic space to get UX designs delivered, otherwise all the strategic discussions don’t turn into anything real.

UX in Marketing

  • Participate in how you appear to your users and customers from an end-to-end standpoint
  • Help enact visual and brand guidance for all products
  • Tie marketing story into the product story more tightly
  • Might not be tightly tied to the product interfaces themselves
  • Might have more of a website focus than a product focus, and might not be able to drive change in product

UX as a Design Organization

  • Builds a team that is viewed as equal and as important as other departments
  • Can create clear growth paths for UX people
  • Can place and pull UX people on projects as seen fit to achieve organizational design goals.  Design is a first class citizen.
  • Getting an organization to head down this path and treat design as a first class citizen can take years, and requires some strong UX and Design leadership as well as total buy-in from the executive level.
  • Need to ensure that all other departments are aligned with the Design Organization to achieve corporate goals.  Design must be a clear part of the culture of how things get done.

UX spread among the company

  • You can put UX with the teams who will really utilize the resources, and they own/pay for the resource meaning they are more likely to use it well.
  • UX can be placed or hired in the right places to create strategic change based on the needs at hand.
  • Typically no clear UX growth path and career ladder
  • When projects change or release, the UX person might be left in the wind without clear direction

Hybrid models

  • Gives you powerhouses in multiple departments, enacting change from multiple directions
  • Drives UX into the minds of multiple organizations, not just one.  Creates a more design-centric culture.
  • Can result in communication mishaps and difference of opinion on direction
  • Might create corporate confusion about growth and careers for design/UX people
  • Have to have the right talent in the right places with a team player attitude, or collaboration amongst design/UX focused people won’t happen effectively.

Determining your plan

Understand your companies overall goals and how UX contributes into them.  If UX contributes by saving money it might be a different discussion than if UX contributes by creating higher profits or by forging into new markets.  Positioning the UX team with the right resources to achieve these goals should be the focus.

Think about where it makes sense for you to sit today, and create a 5-10 year plan for how you might want to advance over time.  Maybe you start living in engineering, but begin to build a UX center of excellence that leads towards a design group.  Maybe you start with product management where you can design new product, but then move towards a hybrid product management and engineering UX/UI Front End Developer approach where you can ensure designs are fulfilled in engineering.

With any plan that you come up with, make sure that you have some champions that you can align your UX goals with in that organization.  Champions should have the ability to influence the organization, and once you get them up to speed they will tell your UX story for you.  Your story is much more compelling coming from these champions than it will be coming from the “UX person” over and over again.

Good luck and leave your experiences and comments below!

User Stories, Scenarios, and Use Cases

Stakeholders use the terms ‘User Stories’, ‘Scenarios’, and ‘Use Cases’ often, and usually interchangeably.  What are these things and are they the same or different?  Well – they are different, and below we’ll go through what they are and when to use them.

Confused by user stories, scenarios, and use cases?

Why are we discussing this?

The next step in our User Centric Design for developers series after knowing your users is understanding what these users want from your product, or in other words, what it is that you need to deliver.  User stories, scenarios, and use cases are all methods of describing user needs.  Any of these can be used by the product team to help define the product in a user-centric manner.  Sometimes one method is more useful than another method, or sometimes you might want to walk through each of these methods incrementally as you learn more and want to capture more detail.


User Stories

User stories are usually a great place to start.  They are quick and easy to capture even through a simple brainstorming session, and they force you to keep ideas user-centric since each feature must have a target user and reason associated with it.  User stories are best known as being associated with Agile development, but can be used with any development methodology as it is just a framework to capture requirements and user needs in.


As a <user type/persona>, I want <feature> so <reason>. 

As a human resource recruiter, I need to record a prospective recruit’s information, contact date, and action items so I can keep track of who I have talked to recently.

User stories are a minimum requirement for project teams to have in my opinion.  Scenarios and Use Cases are more granular than these, and can be used instead.

As a developer, if you are not getting at least user stories – FIGHT BACK!

Demand that you get this level of detail from your product owners.  User stories don’t only tell you what you need to build – they also explain WHY you need to build it and for WHOM you are building it!  This is critical to building a usable, desirable system if you are not in close contact with your users only a daily basis.


Scenarios are narrative descriptions of how a particular persona interacts with a system within the context of their larger environment. Scenarios should elicit emotion when reading them, making us feel empathy for what the user is trying to accomplish.  They typically read like a fictional story, giving readers an idea of all of the surrounding environmental factors that affect a user’s usage of the product.

Scenarios are effective at making the team think about and research the environmental factors and context that a user will be in when using the product.  This can greatly change how you go about implementing a solution.  For instance, if someone typically needs to access your product when they are riding public transit in the mornings rather than once they get to the office, maybe your solution need to focus on easy, mobile controls to work with rather than a complex web application they can only access from their laptop.


Scenario:  Record prospect recruits information

Sarah is on her way into work after a morning doctor’s appointment, and the bus system is taking longer than usual.  Yesterday she had reached out to several new prospects for a VP job she is responsible for filling.  She had to leave a voice mail for two of them.  On her way into work, her phone rings and it is Kevin, the top-most prospect she thinks fits the job at this point.  She talks with Kevin about the position for 10 minutes, and Kevin decides he is willing to move forward with a phone interview with the CTO.  Sarah tells Kevin that as soon as she gets into the office, she will set up the phone interview and send him some further information about the position.  Sarah hangs up and decides she wants to get the information about this call into the system as soon as possible, because she has a lot of other candidates that might call back and she could mix up with Kevin’s needs.  She uses her Android phone to open Kevin’s file and record the call notes and action items she committed to.

Use Cases

Use cases capture further detail of the interaction between the user and the system.  In a systematic way, it captures the steps required from the user and from the system to complete a goal, and any alternative paths that might also exist for this goal.  Use cases are typically more granular and systematic than scenarios, and you are likely to get many use cases out of one scenario.


Use Case:  Record prospect recruits information

Brief Description: As a human resource recruiter, I need to record a prospective recruit’s information, contact date, and action items so I can keep track of who I have talked to recently.

Actor:  Sarah, recruiter


Main Success Path

1. Open software and sign in

2. Navigate to recruit’s list

3. Search for and select Kevin

4. Create new recruit contact note

5. Contact note captures current time and date, can be modified to an earlier time and date.

5. Record call information & action items

7. Save contact note



1. Open software and sign in

2. Find Kevin on dashboard in recent recruit list

3. Create new recruit contact note

4. Record call information & action items

5. Save contact note


Related information

Recruit contact notes will have some pre-filled fields upon entry that can be modified if needed.

With these three tools, the product team can come to a combined understanding of what your user needs from your product, and what driving environmental factors might influence your product design.

In our next step of the series, we’ll talk about moving into the design phase to mock up your solution now that you have an understanding of the requirements and needs of the users.



Informal UX Testing

One of the most useful things a team can do is talk to their users about what they are creating.  Ideally, this happens before you build anything, and then along the way to validate the designs and implementation.  Understanding how the user thinks about the system and how they react to certain designs is crucial to creating a usable solution.

Usability testing comes with a connotation of being a drawn out, complex process that only UX experts can do.  Certainly, there is a place for these formal and controlled usability tests.  They are important for drawing hard metrics that teams can improve against over time, and for gathering full, unbiased feedback on a system.  However, there is also a place for informal usability testing – and in a project where formal usability testing isn’t an option, informal usability testing gives the team a lot of information to use and improve from.



I highly encourage development and product teams to perform their own information usability tests as often as possible.  During a project, about half a day a month is a good rule of thumb for how long you should spend on usability tests – and that includes set up, performing the tests, and organizing the feedback.    Below I’ve laid out a guide that will help you run these tests.


Who do I test?

Ideally, your target users.  In reality, almost anybody.  Recruit loosely, and grade on a curve based on how close they are to your target users.

Getting any person that is not woven into the project team to provide you feedback will show you where you started making assumptions and thought people might be able to follow your logic, but they can’t.  A large percentage of usability issues are due to layout, wording, or design problems that really have nothing to do with the domain.  Almost any user you pick out can help find these problems for you.

Getting your target users is important when you need to test the true workflows and information about the ways that people that use this daily will handle your solution.

For some systems, target users will be more important because domain knowledge is required in order to succeed at the task flows, discussed below.  Once again, you can get some non-target users just to catch layout and design problems.


How do I prepare for the test?

Before the test, you want to identify the task flows/scenarios that you will be having the users perform.  These should be based on the primary use cases defined for your product.  You’re looking to understand if people can find the information they need, and perform the tasks they expect without any problems.  Here’s some examples of scenarios for a usability test:

  • You are traveling to Seattle for your job next week and you want to check on the amount you can be reimbursed for meals and other expenses.
  • You have returned from your trip and you need to scan and add your hotel receipt into a new expense report.

For each scenario you should have an expected outcome or flow that you expect the user to reach so that you know if the user has been able to accomplish the task or find the information if you are not familiar with that part of the product.


How do I run the test?

Once you have your users and your tasks, you can run your test.  There are two main of ways to physically run the test:

In person.  

Get your users in the hallway, lunchroom, a mall, some other public location, or in a private room/office if you have contacted your users ahead of time.   You can show them something on paper, on your laptop, or however you have it designed/built currently.


Get your users onto a Google hangout, WebEx, BlueJeans, or other screen & voice sharing software.  Share your screen with them and give them control of the mouse so they can drive the application on your computer.  With remote testing, always try out your setup before you start to make sure you have it all working!  Volunteering users don’t want to be bothered by your technical challenges.


When you’re performing the test, there are just a few protocols that you want to follow:

  1. Introduce yourself and tell them what you are doing with them and why.  Make sure they know you’re not testing them, your testing your design/software.
  2. Ensure their privacy and confidentiality.  Results should be abstracted from their person.
  3. Give the user the task/scenario, and then be quiet!  When they are trying to perform the task, don’t help them.  If they look to you for help, try to turn it into a question.  “What would you expect the software to do at this point?”  “What would you expect to see here?”  If you start answering their questions, you’ll be leading them and giving them more information than a real user of your software would get.


Want to know more?

A great short book (and I mean short!) that covers informal usability testing is “Rocket surgery made easy” by Steve Krug.  I highly recommend a quick read-through of this if you want to get more serious about including usability feedback into your product development process.


User Centric Design for Developers

Back in April, I gave a presentation at DevNation in San Francisco about user experience for developers.  My goal was to provide both Red Hat developers and our customers some information about how to approach their projects in a more user centric, design first way that will reduce re-work for developers.

Developers spend 50% of their time fixing avoidable issues.  The top three reasons[1] for this are:

  • Badly defined requirements
  • Poor communication between customers, developers, and users
  • Stakeholder politics

User experience focus can help prevent this!

My presentation introduced developers to user-centric design practices, usability testing, and visual design as ways to achieve better use of development time.  The first step to doing user-centric design is understanding who your users are and what they do!


Know your users

The goal of building software is for people to use it.  In order to do this successfully, we need to understand who we are building it for.  For any project, whether it is a point release or a major iteration, you should be able to answer the following questions:

What do my  users do daily?

If you are building something that they use in an office environment, what is their job and what does it entail?  If you are building something that they will use at home, what are their hobbies and daily tasks/needs?

Understand what your users do day to day, so that you can answer the following questions in the context of their typical behaviors and activities.

When will they use my software?

Is your software something they will be using all day, every day?  Once a day?  Once a week?  Once a month?  Once a year?  Know how familiar users will become with your software, so that you can understand where you should be on the scale of simplicity to complexity/flexibility.  Will users remember how to use your software when they come back to it, or do they have to relearn it every time because it has been too long in between uses?

Also, will they use your solution only when they are doing certain other activities or using other systems?  What dependencies and

What else might they do at the same time?

Will users likely be focusing completely on the task at hand in your application, or will they be multi-tasking when using your software?  Are they in an environment where they are likely to get interrupted mid-stream, and need to come back to your software with a sense of where they were and what they were doing?

What are their main goals or tasks?

What are your users actually trying to accomplish (that might be outside of your software)?  How does your solution fit into that bigger workflow?  What is the urgency of their goal or tasks?


Make Personas

Once you are able to answer the questions above for your different users, build out some personas to help you visualize your user types throughout the product development process.  There are many articles on building personas out there, and I’ll add my own soon for more detail on how to do this!


Persona Example

Persona Sheet – build out reference sheets for your personas for easy reference


Doing these two steps for every project will ensure that you understand who your users are and have reference material to help you remember them throughout the design process.  In my next article, we’ll talk about understanding and capturing what these users want from  your product.




The “WOW” Factor

As a user experience professional, I often find I need to provide ways of sharing work and thoughts with a larger audience.  Thus – this blog has begun.


How did I get into user experience?

I have been working in the user experience field for over 7 years.  From the beginning, I was always interested in the fact that companies and organizations have so many wonderful technologies – but many of these technologies, or the capabilities therein, are lost or go unused.  We can build so many amazing things – but these things get lost in the fray unless we can present them in a way that their users will understand and utilize.

Trashing software

How often do you end up trashing software or not going back to websites because they don’t help you?

This began my career in user experience.  I wanted to help teams bring their amazing work to light – to let their users bask in the glow of the time and effort put into building software.  For users to feel excited, delighted, enchanted by the software they  use.  “Delight” is a term talked about often these days in the user experience industry.  But not everything we build is meant to delight in the traditional sense.

Through my history in the user experience field, I have worked on back-office software.  Software that people need to get their daily jobs done.  Most people aren’t going to work looking or expecting delight.  They want to be productive.  They want to accomplish and excel at their job, and they don’t want the software they need to do it to get in their way.  So the first step of any group I have worked with has been removing those barriers – making sure we allow the user to be effective with the tools we are providing them.


Back-office software must allow users to be productive

It is only once we have removed the barriers that we can look to provide the next level, the excitement.  When software is so in tune with what a user needs to do that it helps them do it better than they expected – or provides a widget/tool/capability that the user didn’t even know they needed at the point where they need it, that’s when we can say we’re really providing enchanting, delightful user experiences.  That’s the “WOW!” factor, and that’s what I strive for with every project I work on.


This blog

In this blog, I hope to provide some insight into how I help teams move from difficult to use to the “Wow” factor.  In sharing my work in progress, successes, and failures – I hope that you can learn how to pull some user experience practices into your daily work to improve the user experience of your projects.


– Cat Robson