Blog Archive

Home » Blog

Trade Shows: Returning from the Floor

What to do when you get back from a trade show to maximize your effortsCongratulations! You’ve survived your recent trade show.

Chances are you’re dog-tired, but you still have a lot of work to do. The work you do in the next week or so is going to be vital to considering your trip a success. Once you’re in the office, have packed away all of your equipment, and resumed your normal daily work schedule there are still a few things you’ll want to do to cap off your trade show efforts.

Hopefully, you had a system to write down potential client information and track interactions with those you visited with while on the floor, in breakout sessions, or during on-site meetings. These are potential clients in the purest form – they took time to meet with you and discuss your product! These are the people to reach out to immediately upon returning home. They’ll already be aware of your products or services, your interaction with them will be fresh in their minds, and they’ll already have some level of comfort with you and your offering, having met and spoken with you. Emailing these folks is always an option, but I find it more advantageous to reach out via phone. Direct contact is rare these days, but it’s still the most impactful thing we have.

Once you’ve followed up with potential clients from the show, it can be helpful to take some time for reflection. It’s human nature to strive for improvement and find new ways to do things better – trade shows should be no different.

What did you really do well on the floor? What could you improve? Be honest with yourself and co-workers, as no one is perfect. Were you outgoing enough? Did you appear genuine? Did your booth effectively draw people in from the floor? Did you eloquently explain your product and how it helps potential clients? Try to hone in on the questions to ask yourself and your team during this moment of reflection that would be most helpful in upping your game the next time around.

Finally, plan for your next trade show. There’s always another one on the horizon! Experience is a great educator and I can comfortably say each of my show experiences helps create a stronger performance at the next. When executed correctly, trade shows can become a boom for sales and marketing.

So my advice? Get on the road, talk to as many people as possible, make as many connections as you can, and never be afraid to reflect and improve. What do you think? Did I miss anything? Let me know in the comments.

Related Reading:

Trade Show Success: What to Remember

Don’t Forget About Color Blind People!

So take this quick test: Can you read what’s written within any of these circles?


I can’t! They look just like a bunch of circles with dots in them.

One of the unique things I bring to the table here at Algonquin Studios is that many times people ask my opinion about the look and feel of a site because I’m color blind. My fellow developers want to be sure that the colors they’re selecting aren’t making the site unusable for a color blind site visitor. From my experience,  this is something people often overlook when designing a site.

I have partial color blindness; this means colors mixed together often get mixed up by my eyes. Take the image above; I see an assortment of “colors” but am unable to distinguish what is written within them. Depending on where you get your stats the numbers vary, but by most accounts, a little over 10% of people (the vast majority being male) have some level of color vision definciency. There are many different classifications of color blindness, but a lot of them involve red and green.

In my experience, the most difficult part of viewing a web site is when a color is used as a legend to indicate something on an image or chart. When my eyes are forced to go back and forth to see what each color represents, it’s often hard to know what matches with what, especially if there the color difference are subtle. I find what often helps me is if there are also images used to relate to each section. If you’re building the color schemes for these types of legends, I’d suggest it’s best to avoid red/green shades as they are most common in partial color blindness. Instead, use blue! It’s a far less prevalent issue among the color blind community.

There are applications available that can assist those with color blindness. Google Chrome has a nice free extension called “Spectrum” which allows you to choose which aspect of color vision deficiency you have and helps you change the colors on the sites you visit accordingly. I often use Spectrum when I’m playing a game online and need to more clearly differentiate the opponent I’m battling against.

So when designing a site, it is good to keep your color blind users in mind. And, if you failed the test above? Congratulations, you’re partially color blind! I’d suggest doing some research on which bucket you fall into and downloading the appropriate application to assist your web browsing.

Related Reading:

Wikipedia Entry on Color Blindess

Tips for Designing for Colorblind Users

Leveraging SQL DMVs for Procedure Analysis

Microsoft SQL ServerAs each new edition of Microsoft SQL Server is released, the ability to track and analyze database metrics is expanded. Dynamic Management Views (DMVs) provided developers and DBAs state information regarding the health and performance of their database server.

In this post, I am reviewing one specific DMV that I have used – Cached Procedure Statistics – that are stored in the “dm_exec_procedure_stats” table. I’ve used this DMV often to gain insight into 3 key factors:

  1. Monitoring when SQL Server is caching the stored procedure
  2. Determining the average execution time of a stored procedure
  3. Determining how often the stored procedure is being executed

I’ve included my query below, which is very similar to, but slighty adjusted from the query that Microsoft provides in its MSDN article (link below). I’ve limited down the query to information that provides a high-level overview of the application’s performance. The “dm_exec_procedure_stats” table provides additional procedure information – worker time, physical read/writes, logical read/writes – beyond what I discuss below.

  • Cached Time
    • Generally speaking, if your cached time is continuously reset, SQL Server is removing the procedure from its cache in order to free up memory for something else. This can be a sign that you have memory constraints on your database server.
  • Average Elapsed Time
    • In my query, the results are returned in order of longest average elapsed time first. These are the procedures that are generally doing the most work in the database. The average elapsed time will be adversely affected if SQL Server is constantly having to dump its procedure cache, but procedures with the longest execution time are usually re-reviewed to ensure that the procedure is running as efficiently as it can be, and and re-written if necessary
  • Execution Count
    • I generally review the execution counts as well. For the procedures that are being called the most, it’s generally worth reviewing whether you need to call the procedure as often as you are
      • Are you always executing the procedure with the same parameters? Then you can probably cache the data somewhere else (i.e. session, page View State – based on the size and nature of the data) and reduce the calls to the database
      • If your procedure needs to be called as often as it does, are you limiting it to only query and return necessary data?

So what if your procedure is not visible in this DMV? Then SQL is not caching the execution plan. This can be by design, or it can be a sign of another issue. You’ll need to know more specifics about the procedure in order to determine this, but it’s generally worth following up on.

Here’s the MSDN article that contains more information on the procedure statistics: 

DECLARE @intDatabaseID INT

SET @intDatabaseID = db_id('myDatabaseName')

'proc_name' = OBJECT_NAME(object_id, database_id),
'avg_elapsed_time' = (d.total_elapsed_time/d.execution_count),
sys.dm_exec_procedure_stats AS d
database_id = @intDatabaseID
[avg_elapsed_time] DESC

Build Me This Feature. It’s Easy, Right?

Building custom software is "easy" right?What is it about technology that’s so intriguing? There are probably many things, but one is certainly the fact that technology has taken very complex, time-consuming ideas and tasks and made them more simple, allowing the Average Joe to do things that he could never have considered before.

How would you have planned and marketed a church fundraiser like a baked goods sale 20 years ago? You probably would have posted sign-up sheets in the church foyer; you’d have made announcements before service started; you’d have typed fliers, photocopied them, and handed them out as people were leaving the building. You’d have had to manage volunteers, schedules, recipes, cash payments (and maybe even receipts) and more, all using paper…Lots of paper. And it would have been incredibly time-consuming. But now, you can create events and handle web-based registrations using tools like Eventbrite. You can post information about your event on Twitter and Facebook. You can even accept credit card payments using your smartphone.

Our “smart” phones and appliances do things with a simple swipe or click; sometimes they even do things without any prompting from us. The machines just know. We use so many applications throughout our day that we forget about the thousands of calculations and processes that are built into the proper execution of the tasks these tools are helping us accomplish.

And so, it’s understandable that people often believe the feature or functionality they want built into their web site or mobile app is “Simple, right?” After all, the feature they’ve asked you for is “only doing X,” how hard can it be to implement!? Relative to Google’s attempt at self-driving cars, your client may be right – their request could be pretty simple. But, relative to the quick click or swipe an end user enacts to make the feature “go,” the development and deployment of a new feature is rarely simple.

I’m a Sales Consultant, so what’s the next assumption I often hear about these “simple” feature requests? Well, if it’s a simple feature, then it must also be an inexpensive feature, right?

People forget about the requirements analysis time required to make sure we’re going to build a feature that does exactly what they want it to do. They forget about the time it takes to document these requirements and create a development and testing plan around them. And they forget about the time it takes to complete that quality assurance pass once the feature’s built. Let alone the actual development effort, which is often under appreciated in and of itself!

Good software development takes time and it’s a mistake to assume the under-the-hood effort to perform the functionality you’re requesting is “easy.” My advice? Go with someone who’ll insist on doing it right the first time, which can mean spending more time and/or money, or you’ll be paying them, or someone else, to fix it later.

Burying Windows XP with IE11 Enterprise Mode

Note: this post first appeared on my blog on April 8, the last day of Windows XP support.

Chart showing that IE8 is the browser common to Windows XP and Windows 7.
Screen shot from Microsoft’s presentation on IE11 Enterprise Mode, showing what browsers are available on what versions of Windows. Note that the Venn-ish diagram has no IE11 intersection for Windows 8.

As of today, Windows XP has effectively reached its end of life. What I mean by that is that Microsoft will no longer be releasing security patches for Windows XP. Those of you waiting to deploy those XP exploits can run at the platform unopposed.

While this may be a nuisance for the home user (and the family who acts as his/her tech support), this has larger implications in the business world. For example, if you work in the healthcare world you may very well be in violation of HIPAA / HITECH laws if you’re still running Windows XP tomorrow.

What’s really annoying about this is that so many web-based applications were built to support the dominant browser(s) at the time — Internet Explorer 6 through 8. What that means is users on Internet Explorer 11 are being locked out of these online tools, making the transition away from Windows XP (which cannot have a version of IE greater than 8) a tough proposition for organizations.

Simply put, poor web development practices have created an environment where upgrading to the latest version of IE is directly at odds with keeping your productivity up (if it requires you to stay on an old version of IE). Complicate that by now making that old version of IE a vector for security breaches and compliance penalties/lawsuits.

But fear not! As long you have the hardware and licenses to run Windows 7 or Windows 8.1 (notice, not Windows 8), you can still use those Internet Explorer 8 web sites without being locked out (you’re SOL if you need IE6).

With a week before Windows XP turns into a zombie, Microsoft released Enterprise Mode for Internet Explorer 11. After all, you only needed a week to get all that hardware in place and configured, right?

Enterprise Mode doesn’t just emulate IE8, it masquerades as it. Some of the benefits of Enterprise Mode:

  • Enterprise Mode sends the IE8 user agent string to defeat misguided browser sniffers;
  • it mimics the responses IE8 sends to ActiveX controls, ideally allowing them to keep working;
  • it supports features removed from later versions of IE (CSS Expressions, woo hoo!);
  • pre-caching and pre-rendering are disabled to keep from confusing older applications;
  • IE8′s Compatibility View is supported, so odds are many applications designed for IE7 will work.

Some web developers have panicked that now they’ll have to support another browser or browser mode, but so far the evidence doesn’t bear that out.

Enterprise Mode will be controlled by a central source, most likely corporate IT departments, and will only be enabled for sites that have been manually identified. Intranets and custom-built un-maintained web-based applications are an easy fit here. If an IT department deems it appropriate, it can also allows end users to decide to enable Enterprise Mode on a site-by-site basis.

Microsoft has been testing this in many industries and countries (though not China, the biggest culprit for old, and illegal, versions of Windows). Hopefully this will help speed users to upgrade to IE11, even if it doesn’t provide motivation for organizations to upgrade their legacy IE8 applications.

In addition to the links above, you can get more information from the video of Microsoft’s Enterprise Mode presentation, or you can just view the presentation slides alone.

In short, this is a great band-aid for organizations that already have Windows 7 or 8.1, but won’t be helping to push IE8 out of the way (despite the best efforts of some). In short, as web developers, we can expect to support IE8 for a while still.


With the demise of Windows XP (even though we know it’s not suddenly gone today), Internet Explorer 6 is also at its end of life (because no supported platform can run it). We know that it won’t go away completely, but it’s still being celebrated at sites like

Update: April 11, 2014

I mentioned HIPAA above and linked to a post that argues for the presence of Windows XP as an automatic HIPAA violation. A more balanced, and well-cited, post is on this very blog: So You’re Stuck with Windows XP but Still Need to be HIPAA Compliant

So You’re Stuck with Windows XP but Still Need to be HIPAA Compliant?

It’s official. Microsoft has ended support for Windows XP.  In an ideal world, we’d all be running up-to-date operating systems on blazingly fast, new hardware. Unfortunately, that’s just not the world we live in. Many organizations are still “stuck” with Windows XP and may be for some time.  This may be because of financial constraints, resource saturation, or something else altogether.  Regardless of the reason, if you find yourself in this situation today and you work with EPHI, you’ve got some work to do to mitigate your risks under the HIPAA Security Rule.

If you do a web search for “Windows XP and HIPAA Compliance” you’ll find two very different schools of thought.  First, you’ll find the folks who claim you’re automatically non-compliant if you have a single Windows XP machine on your network.  A good example of this is No HIPAA or Meaningful Use Compliance with Windows XP.  The other camp argues that it’s not so cut and dry. They suggest that you conduct a thorough Risk Analysis of your environment and take whatever action is most “reasonable and appropriate” for your particular situation.  My favorite examples are HIPAA Bull**** about Windows XP and Is Your Health Insurance Portability and Accountability Act (HIPAA) Compliance Program Going Out the Window with XP? Both articles recommend a very sensible course of action.  They aptly point out that “there is no one-size-fits-all approach to compliance with the HIPAA Security standards” and that certainly applies to the use of Windows XP.  Let’s take a closer look.

What does the rule say?

Here it is, right from the horse’s mouth (i.e. the HHS web site):

PROTECTION FROM MALICIOUS SOFTWARE (A) – § 164.308(a)(5)(ii)(B) One important security measure that employees may need to be reminded of is security software that is used to protect against malicious software. Where this implementation specification is a reasonable and appropriate safeguard for a covered entity, the covered entity must implement:

                “Procedures for guarding against, detecting, and reporting malicious software.”

Malicious software can be thought of as any program that harms information systems, such as viruses, Trojan horses or worms. As a result of an unauthorized infiltration, EPHI and other data can be damaged or destroyed, or at a minimum, require expensive and time-consuming repairs.  Malicious software is frequently brought into an organization through email attachments, and programs that are downloaded from the Internet. Under the Security Awareness and Training standard, the workforce must also be trained regarding its role in protecting against malicious software, and system protection capabilities. It is important to note that training must be an ongoing process for all organizations.

There are two things of note here:

1. The (A) in PROTECTION FROM MALICIOUS SOFTWARE (A) stands for “Addressable.” This means we must implement this standard if it’s reasonable and appropriate to do so. HHS states, “This decision will depend on a variety of factors such as, among others, the entity’s risk analysis, risk mitigation strategy, what security measures are already in place, and the cost of implementation.”  Here’s a link to the complete HHS explanation.

The “Addressable” classification gives you options. It allows HIPAA to push organizations towards “best-practice” without enforcing a rigid framework that makes it difficult for them to adapt and stay in business.

2. HHS focuses on the importance of training your staff. This is a huge factor in mitigating any type of risk identified in your analysis.  It’s certainly advisable to have clear guidelines governing the use of your organizations technical infrastructure and to educate your staff on the various risks that they can help to mitigate.

What should you do right now?

First and foremost, conduct a thorough Risk Analysis. If you haven’t done so, you’re officially “non-compliant,” regardless of anything else.  If you don’t know where to begin, check out the recently released HHS Security Risk Assessment Tool. 

If you’ve identified risks to EPHI tied to your continued use of Windows XP and aren’t in a position to move away right now, you should address the issue directly and in writing.  Explain why it’s not currently feasible for your organization to migrate and create a plan that lays out how and when you will (or at least establish a date for reevaluating the move).  Then, identify the steps you have taken (or will take) to mitigate the risks. Maybe you’ll isolate the machine(s), update network usage policies, or conduct updated staff training.  Whatever the risk, you can always do SOMETHING to reduce it, even if only slightly. 

This is HIPAA Compliance

HIPAA-Compliance is not a checklist.  It’s a process, a way of conducting business.  It’s the process we just walked through.  Don’t take advice from folks who speak in black and white and generalize the whole rule.  Do your due diligence and document your decisions.  Establish a routine for constant review and improvement and keep your policies in order.  If you do that consistently, you’ll always be “audit-ready.”   That is the spirit of the rule.

Disclaimer: This post is intended to advocate a way of thinking when it comes to compliance with the HIPAA Security Rule.  I don’t recommend the continued use of an unsupported OS in any computing environment, if it can be avoided.  But, if you are stuck with one, don’t stick your head in the sand.

More on HIPAA from Donald F. Lee III:

The Subtle Value of a Good Partner

How do you instill loyalty in your clients?Recently, I was making small talk with one of our clients while waiting for others to join a conference call. He mentioned problem he was having, trying to make web-based presentations to his clients, so I brought up the free screen-sharing software I use for my own presentations. We’d both joined the call early enough that I had some time to show him a few features on the platform.

The  original purpose of our call was to discuss a web site redesign, but I think the real value for him became learning about the tool I was using and asking me questions about implementation. In fact, I got the feeling that at some level he was disappointed when we were interrupted by the rest of the conference callers joining in for our scheduled meeting!

“The Internet has changed the world,” says Captain Obvious. And, for the most part, I think the changes have been for the better. But, one thing that’s challenged by our ability to do more research and find more options (locally, nationally, even internationally) is loyalty – do some research and you can probably find someone who can do it cheaper and faster. If cheaper and faster are a client’s main priorities, it can be difficult, as a professional services company, to foster a good, long-term relationship because the client might bounce from one vendor to the next, looking for the “best deal.”  But, what about the vendor who’s willing to spend more time with you? The one who’s happy to help you with an issue that wasn’t even on the agenda that day? Let’s not forget the less obvious value this vendor brings to the table. Sure, he might not be the cheapest or the fastest, but I’m willing to bet he’ll actually be the “best deal” in the long run.

Circling back to my client on the conference call – I can’t know for sure, but I hope that the next time he’s looking for some insight or information on a new technology or software implementation, he’ll think of our conversation. Hopefully, he’ll give me a quick call and I’ll answer my phone and give a few minutes of my day to help, regardless of the short term benefit to me. Because that’s how you build strong relationships and inspire client loyalty – it’s simply what good business partners do.

Own More of Your Startup: Mitigate Execution Risk and Get to Market Sooner

Archers, Mark Fischer, FlickR Creative CommonsMaybe you have a good idea to launch a business; minimizing execution risk could make it real sooner. I’ve got a hypothesis and I haven’t found much in the way of evidence to support or refute it. What do you think about the notion below?


I’ve met a lot of pre-seed startups recently. It seems like every entrepreneur opts for a team of developers as early as they possibly can. Why? Would you build a manufacturing plant for an emerging product? Most likely no, you’d hire an existing contract manufacturer to take care of production (and a fulfillment warehouse and shipping carrier too), while you focus on the unique aspects of your business.

So, what anxiety drives startups to bulk up on developers first?

As an entrepreneur, you might think along lines such as:

  • Good developers are scarce, perhaps more so than architects, carpenters, plumbers, electricians, and roofers.
  • You might fear getting enough access and control without your own dedicated team.
  • You want to see your dream built, as a way of validating that it can be built.
  • A working product attracts customers. With more development comes more value to the customer.
  • You may believe that your team needs to eat, breathe, and sleep the product in the same way that you do. No one else could bring it to life without living inside it – requiring specialist knowledge.

Trade Off

Let’s challenge the idea that you need a dedicated development team out of the gate. First, I’ll oversimplify the venture capital game, since I think it’s the core problem an entrepreneur is trying to solve. You might ask, “How can I raise enough capital to get my business off the ground without diluting my share so much it’s not worth it?” You dilute your ownership funding in each round that you close. Yet, you can’t start work on your product without funding. You could pay your developers in pizza and beer, but they’ll also take some ownership too.

To preserve as much ownership as possible for you, one strategy would be to minimize rounds and ask for everything you’ll need in the first round. However, you’ll learn as you go and you may find you need more. That takes us right back to the problem: retaining a share that’s large enough to be worth it (however you define “worth it”).


Another way to go would be to drive up the valuation of your business, and that’s where my hypothesis begins. If you still need the same amount of capital to launch it, then a higher valuation would reduce the share that your investors get.

How can you increase the valuation?

Often, I see early development efforts proving that the product could be built. What if you could skip that stage confidently in a way that satisfies your investors? If you aligned with a software development firm with a proven track record, investors may discount your “execution risk” and move ahead to your ability to attract a market of customers. By spending your initial efforts on validating your market, say by signing up customers contingently on the delivery of your product, you could come back to the table saying, “With this effort I’ve attracted quantified customers who have agreed to pay and they gave us this feedback.” That should change the conversation from an unknown customer reception to a marketing path to build on. That’s valuable.


You’ve just side-stepped a whole bunch of execution issues with developers:

  • Developers are expensive and the war for talent makes it competitive (read: expensive).
  • How do you know you’ve hired the ones you’ll actually need as your business rapidly evolves? Can you get a team with broad enough coverage for your budget?
  • The team often hasn’t worked together before.
  • It’s rare that the developers are doing something completely new, so there may not be anything globally unique about them.
  • You have a dream, so it’s easy for your team to lack clarity on priorities, scope, value, and effort, leading to wandering output, exceeding your budget, and late deliverables. Can your team do a good job of managing your expectations? Can you really control developers the way that you believe?
  • Do you really want developer management to be the determining factor in your success?

Most of the metrics I see that gauge a software-as-a-service (SaaS) startup’s success center on the monthly recurring revenue, churn, cost to acquire customers, average revenue per customer, and lifetime value. Basically, you need to keep your operating costs low enough while gaining new customers that you get to positive cash flow before your startup capital runs out. Even if you’re pre-seed, you still have startup capital in the form of long hours volunteered by your founding staff.

Partnering with an experienced software development firm could get you focused on these metrics much earlier. You’re not skipping development cost; you’re making it more predictable, and possibly lower. A good development firm should do a good job of keeping your expectations managed and your project on-budget and on-time. They’ll ask for your commitment to a process that validates ideas first. They may even handle hosting, support, IT, and security, too.

When your in-house team misses a budget or deadline despite their efforts, can your culture survive it? You can hold a partner firm more accountable, without sacrificing your in-house team’s commitment.

I’d love to read your observations and some studies that support or refute this idea, especially from experienced investors and entrepreneurs. Please share in the comments below!

Further Reading

Trade Show Success: What To Remember

How to make the most of your trade showAs I write this, I’m preparing to travel to a trade show in Dallas and have been thinking a lot about the preparation, execution, and follow-up needed to have a successful experience at a trade show.

There are many variables to consider while attempting to conduct a successful trip and some of these will scream an obvious “Duh!” but my ultimate goal is to get you, the reader, to think about what you would do with the ideas I present.

I call the first stage of trade show prep “pre-planning.” While pre-planning, there are several tasks to consider and cross off your to-do list. First, gather your trade show materials. These include any booth items such as backdrops, advertisement pieces, tables, and take-aways for potential clients. Now is also a good time to check and double-check (hey, may as well triple check) your flight situation and hotel accommodations. I’ve heard horror stories of people going to shows in faraway cities just to arrive to cancelled hotel rooms – be vigilant! It’s also a good idea to set up visits with both current and potential clients whose offices are located in close proximity to the show. After all, you’ve flown across the country, shouldn’t you take this opportunity to meet those folks face-to-face and create a deeper relationship?

When you’re all set, pack up and get ready to go…And don’t forget to bring some comfortable shoes!

Once you’re at the trade show, your primary goal should be to meet potential clients and learn about the problems and pain points they’re facing to determine whether you have a solution that can help. Introduce yourself to people; make the first move. I plan to be a social tornado out on the floor – why go to a trade show if not to talk to as many people as possible? Having things to attract people to your table like give-aways, interactive displays, and demos is definitely important, but making sure you have a system to record information about your interactions with potential clients is the real key to a successful show, because that’s what will help you engage in meaningful follow up when you get back to the office.

If you’re tired, sore, and possibly hoarse at the end of the day; you’re doing it right. Buck up, chances are there’s a reasonably comfortable hotel bed awaiting your arrival!

Much like the idea of planning visits to your clients’ and prospects’ offices, it’s also a good idea to schedule activities with potential clients at the event, but away from the show floor. Dinners or drinks are good ideas – social activities keep things casual while developing a good dialogue with room for future business opportunities. You can also enlist your local clients to help you enjoy their city, bringing along a few potential clients from out of town (after getting the A-OK from the local folks, of course). Sightsee, go to a sporting event, check out a local museum or stage show…Whatever works for you and your prospects. I’ve definitely found that potential clients will remember and appreciate the people that got them away from the convention center for a few hours and helped them experience something new.

Of course, all of this effort will only pay off if you make it a priority to follow up with and re-engage those people at the show who were receptive to your message and in need of your solution.

Then, take a nap. You’ve earned it.

Who’s Using Your Software?

Who is using your software?

Recently, our team was working on a designing a new system for a Health Information Organization. The system was designed to maintain the contact info (name, address, phone number) and other relevant information for health care providers and organizations within the Organization’s region. I did most of the Requirements Analysis for this particular project, and was very excited to see it approved by the client and sent off for development.

Once development was underway, our team naturally had a lot of questions and I was able to answer most of them, based on my understanding of the client’s needs, the nature of the business, and the expectations of the system. However, some questions arose that I was unable to answer because I hadn’t thought to pose these types of questions to our client when gathering requirements. These questions were all related to User Experience – a concept that, at the time, I hadn’t spent much time thinking about.

User Experience essentially encompasses all aspects of the end user’s interaction with a company, its services, and its products. And when developing software with a good user experience in mind, you’ll want to make sure you ask you client questions like:

  • Who is going to use this software?
    • External (clients, patients, etc.) or Internal (employees, doctors, etc.) Users?
  • Why do they need this software?
    • What problem will this software solve?
  • How are they going to interact with the web based application?
    • Web browser, mobile interface, or both?
      • If a web browser, which one(s)?
  • What parts of the system will be used most frequently?
    • Where will the majority of users spend most of their time?
    • What is the primary action of the user on this screen?

You’ll want to ask these questions during Requirements Analysis (RA), and check back against them each step of the way, so that your software  is designed, and eventually built, with the end users in mind.  This is important – always remember, it’s not for the people designing it; it’s not for the people building it, it’s not even for the people paying for it – your software is for the people that will ultimately end up using it.

When I conducted my RA sessions with the client, I was defining the requirements and asking my questions as if I would be the end user – my main concern during RA was the tracking data. I made sure I identified every piece of data the user needed to maintain, how it was related, and how they were able to search, add, edit, and modify it. Of course, as an architect of the system, if I was  logged in, I would know where to go, how to get there, and what to do to accomplish a task, but would it be as simple for the end user? Would the actual users be able to the meet the hardware and software requirements I’d failed to define in Requirements Analysis?

Asking user experience questions will help you specifically identify who’ll interact with your software and how they’ll do so. If one part of your system will be used 90% of the time, you should focus your efforts to make sure that part is the most effective and provides the most value to those using it. After all, what good is a system if the people who need it most can’t use it well?