{"id":5890,"date":"2013-04-23T09:15:54","date_gmt":"2013-04-23T14:15:54","guid":{"rendered":"http:\/\/www.mrc-productivity.com\/blog\/?p=5890"},"modified":"2022-11-22T13:16:36","modified_gmt":"2022-11-22T19:16:36","slug":"how-to-build-applications-your-users-will-hate","status":"publish","type":"post","link":"https:\/\/www.mrc-productivity.com\/blog\/2013\/04\/how-to-build-applications-your-users-will-hate\/","title":{"rendered":"How to build applications your users will hate"},"content":{"rendered":"

\"Education\"<\/a>IT departments are often frustrated by poor application adoption. They spend months building applications for their end users, only to see low adoption rates upon completion. The very users that begged the IT department for the application don\u2019t use it once it\u2019s built.<\/p>\n

Why? What causes low user adoption? What makes users dislike an application that they themselves begged the IT department to deliver? <\/p>\n

While there\u2019s no single answer, user adoption problems typically stem from several common mistakes. Which mistakes? We posed this question to a few experts and have included their advice (along with some actionable takeaways) below. User adoption problems usually occur when developers…
\n<\/a><\/p>\n

1. Ask the wrong questions<\/h3>\n

Assuming that the end user knows exactly what they need is one of the biggest mistakes developers make. As many developers learn, end users don\u2019t always know exactly what they need…as much as they might think otherwise.<\/p>\n

\u201cDevelopers are often literal thinkers and will sometimes assume that what the user asks for is exactly what they need and want,\u201d says Jenson Crawford<\/span>, an experienced Software Engineering Manager. \u201cThis, however, is a disastrous assumption. As a software manager, part of my job is to make sure the developers are asking the right questions to understand, what business problem the users are trying to solve, and to help the developers collaborate with the users to design and develop a successful application.”<\/p><\/blockquote>\n

The takeaway<\/strong>: Don\u2019t simply ask users what they want. Ask them what problems they are trying to solve.<\/p>\n

2. Only involve users at the beginning<\/h3>\n

Some developers only involve users at the very beginning of the project. The users explain what they need and the developers go off and spend a few months building it. When it\u2019s finally completed, the users aren\u2019t happy. Why? There was no communication during the development.<\/p>\n

\u201cAnother key is to keep the users involved during the design and development process,\u201d explains Crawford. \u201cTraditionally, IT departments would build an application to specifications provided by users and then show the application to users only when it was complete. A better approach is work collaboratively with the users, showing them designs and demonstrating features as they are developed. Early feedback provides communication that is crucial to building a successful application.\u201d<\/p><\/blockquote>\n

The takeaway<\/strong>: Communicate with users throughout the entire development process, not just at the beginning.<\/p>\n

3. Involve the wrong users<\/h3>\n

Many times, management decides they need an application without consulting the very users who will use it. The developers work with the managers throughout the entire process and create exactly what they ask for. Unfortunately, it\u2019s not what the real users need.<\/p>\n

\u201cToo many companies keep the project top secret until it’s finished and then spring it on the end users and say, \u2018tada, look at this new whiz bang\u2019, says Eric Scott, CEO of Dolphin Micro<\/span><\/a>. \u201cThe users often say, \u2018uh, neat, it doesn’t solve any of my problems and will just take extra time for me to use.\u2019 Adoption rates are poor because it solves high level ideas of problems the VPs have, but not the in-the-trenches problems that the workers tackle in their day-to-day jobs.\u201d <\/p><\/blockquote>\n

The takeaway<\/strong>: Make sure you\u2019re talking with the actual end users during the project, not the managers who think they know what the users want.<\/p>\n

4. Build it slowly<\/h3>\n

Many IT departments collect the specifications from the users, and then spend months (and sometimes years) building the requested applications from scratch. By the time they\u2019re done with the project, the business needs have changed. So, now the users have what they asked for, but it\u2019s no longer what they need.<\/p>\n

“In today’s evolving business environment, it is critical to deliver solutions to users in a timely manner,” says Rick Hurckes, Lead Consultant at mrc<\/span><\/a>. “I’ve seen cases where solutions take many months to deliver. By the time the solution is at the user’s fingertips, their needs have already changed and the solution provided is out-of-date, ineffective, and ultimately, goes unused. Rather than building solutions from scratch, I advocate using a development platform. It accelerates your application development cycle, allowing you to better meet the needs of your consumers.”<\/p><\/blockquote>\n

The takeaway<\/strong>: Don\u2019t try to re-invent the wheel when developing business web apps. A development tool\/platform will automate much of the tedious coding and cut months off of the project.<\/p>\n

5. Provide inadequate training<\/h3>\n

When you boil it down, low user adoption rates are usually caused by two problems: Users either don\u2019t understand how the application will help them, or they don\u2019t understand how to use it. Proper communication and training will help your IT department address both issues.<\/p>\n

“Most of the companies we’ve seen poor adoption rates with tend to develop the app in secret, release it with fanfare at the company meeting to “train” everyone, and then send out a few emails and wonder why it doesn’t take off,\u201d explains Scott.\n<\/p><\/blockquote>\n

He goes on to explain the two most important keys to good training: <\/p>\n

1. \u201cPurpose<\/strong> – the users need to understand what problems the software solves, FOR THEM. Project manager, programmers, line workers, and hr people are busy. They don’t care about what the big-wigs at corporate want. They have a job to do. If you train them on how the new system makes their jobs easier, they’ll be more inclined to use it.\u201d<\/p>\n

2. \u201cFrequency<\/strong> – one training day isn’t enough. You’ll need an ongoing training plan. The first training should show them why the new system is good and a brief tutorial on how to use it. A second training covers the info again for those that haven’t had time to use it, answer questions for those that did, and show some tips and tricks for the power users. Additional bi-annual or annual trainings are critical for new hires and to teach best practices for use.\u201d<\/p><\/blockquote>\n

The takeaway<\/strong>: Don\u2019t simply teach users how to use the application. Explain how it will help them solve problems they face on a daily basis.<\/p>\n

Bonus: Ignore the user experience<\/h3>\n

Sometimes, you do everything right. The application solves a user problem, you\u2019ve involved the users from the start, and you even trained them perfectly. But, users still hate your application. Why? Often, it\u2019s a result of a frustrating user experience. <\/p>\n

While there are many such examples, issues like a confusing interface, cryptic error messages, no data persistence, and over-zealous security measures will frustrate users to no end. If you’d like to read more on the subject, this article lists 7 such errors to avoid<\/span><\/a>.<\/p>\n

The takeaway<\/strong>: The interface must be user-friendly and free of annoyances if you hope to improve user adoption.<\/p>\n

Wrap up<\/h3>\n

For a developer, delivering an application that users hate is a horrible feeling. You\u2019ve poured months of effort into the project, and built exactly what the users asked for…but they don\u2019t use it. If you\u2019d like to avoid that problem, make sure you avoid the problems listed above in your next development project. Of course, if you can add anything to the list above, please share it in the comments.<\/p>\n","protected":false},"excerpt":{"rendered":"

IT departments are often frustrated by poor application adoption. They spend months building applications for their end users, only to see low adoption rates upon completion. The very users that begged the IT department for the application don\u2019t use it once it\u2019s built. Why? What causes low user adoption? What makes users dislike an application …<\/p>\n

How to build applications your users will hate<\/span> Read More »<\/a><\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"default","ast-global-header-display":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","slim_seo":{"title":"How to build applications your users will hate - mrc's Cup of Joe Blog","description":"IT departments are often frustrated by poor application adoption. They spend months building applications for their end users, only to see low adoption rates up"},"footnotes":""},"categories":[8],"tags":[13,43,15],"class_list":["post-5890","post","type-post","status-publish","format-standard","hentry","category-education","tag-application-development","tag-usability","tag-web-development"],"_links":{"self":[{"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/posts\/5890","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/comments?post=5890"}],"version-history":[{"count":41,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/posts\/5890\/revisions"}],"predecessor-version":[{"id":14036,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/posts\/5890\/revisions\/14036"}],"wp:attachment":[{"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/media?parent=5890"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/categories?post=5890"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/tags?post=5890"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}