Menu Search
Jump to the content X X
SmashingConf London Avatar

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf London, dedicated to all things web performance.

How To Build A Better Web Application For Your Business

Are you fed up with hearing about yet another Silicon Valley Web application built with fairy dust and funded by magic pixies? If so, this post is for you. Most of us will never get to work on a Web application that is funded by venture capital and for which the business aims are a secondary consideration. For us, developing a Web application is about meeting a particular business need as part of our job working with some large organization.

Whether as an in-house developer or as part of an agency, we work under strict business constraints and with limited budget and time. Personally, I thrive on this. But it is challenging, so finding the right approach is crucial. In my time of working on Web applications for businesses, I have identified three secrets that seem to make things go a lot smoother:

  1. Focus on user tasks and not features,
  2. Don’t try to solve everything and
  3. Ask the right questions early on.

Let’s begin by looking at user tasks:

Focus On User Tasks, Not Features Link

When you’re asked to build a Web application, you do exactly that: build a Web application. You have not been asked to solve a business problem, nor to make it easy for the user group to complete a particular task. Instead (at least in my experience), your job is to add certain features and build a specific type of application.

Further Reading on SmashingMag: Link

Unfortunately, this is a dangerous approach. By focusing on the application you are building, the emphasis is firmly on technology and functionality, not the users’ needs or the underlying problem to be solved.

Take a Step Back Link

A good development team will step back at the beginning of a project and look at the underlying issues that have led to the application being initiated.

  • Spend time with those who will use the application. Observing how users complete the tasks you are trying to simplify is more enlightening than any specification document.
  • Actually speaking to those who will be interacting with your application on a daily basis will create a much more effective solution than blindly following the directives of whoever commissioned the project.

Make User Testing Part of the Development Process Link

User testing is key to getting to know the user. Aim to test the application at least once a month throughout the entire development cycle. This does not need to be expensive or time-consuming. Rather, each session needs only three or four users and should be easily completed within a morning. This allows the entire development team to take part in these sessions and be involved in the debriefing, which can happen over lunch.

Rocket Surgery Made Easy5
For more information on this “budget” approach to usability, I recommend Steve Krug’s latest book Rocket Surgery Made Easy6.

When it comes to building Web applications for the business, task completion is king. Features merely exist to help users complete tasks.

Which brings me to the next secret…

Don’t Try To Solve Everything Link

If you fail to stay focused on user needs and business goals, things can get out of hand. These kinds of projects tend to suffer particularly badly from scope creep. Once people in your organization see the potential of the application, they will start suggesting ideas for new functionality. The problem is that with every new feature comes more complexity. This can ultimately undermine the effectiveness of the app. When developing a Web application, I urge our clients to start simple.

  • Predicting how users will respond to your application can be hard, and a lot of time and money can be wasted building features that no one actually uses.

Monitor Your Key Performance Indicators Link

Once the simple application has launched, move into a phase of monitoring key performance indicators. This will help you judge the success of the app.

The indicators will vary between projects. However, establishing at the beginning of the process how the success of the app will be measured is important. Combined with user feedback, this monitoring provides a clearer picture of where you should go next. But be careful with user feedback.

Don’t Overreact to User Feedback Link

Users often react negatively to change. Learning a new system takes time, even if it ultimately is easier to use. Users will inevitably complain and make a plethora of suggestions.

Don’t react too quickly to these suggestions. Daniel Burka7 once told me from his time at Digg that they allow at least two weeks before reacting to user feedback. Allow users time to adjust to the application before making changes.

We hate the new Facebook group
Users don’t like change, as Facebook has discovered.

But that is not an excuse for ignoring the opinions of users. In fact, you should carefully gather as much feedback as you can.

Sometimes Technology Is Not the Answer Link

Interestingly, many of the suggestions made by project stakeholders (not users) revolve around management issues, such as reporting, workflow and monitoring.

While these suggestions are sometimes valid, I have found that the simplest solution to these problems is usually managerial, not technical. For example, a number of clients have asked me for workflow functionality in their content management systems, so that documents cannot be published without approval from elsewhere in the organization. Of course, this is entirely possible to build. In fact, it comes standard in most content management systems.

But I usually wonder whether it would be easier just to tell content providers not to publish a document before it’s checked by someone else. Does this really need a technical solution when a simple policy would do the job?

If more features add more complexity, perhaps we should not solve every problem with a new feature. We could always add that functionality later if it really is required. Of course, that depends on whether the application is easy to expand.

Make It Expandable Link

Because our feature set is likely to change based on user feedback and business aims, building the application in anything but the most flexible way would be unwise, especially if we purposely haven’t added all of the intended functionality for launch.

Making an application flexible is obviously not easy. But if the application has a plug-in infrastructure from the beginning, then adapting it over time becomes easier. The trick is to recognize from the outset of the project that you do need flexibility. Which brings us to the next point:

Ask the Right Questions Early On Link

When building a Web application, nothing is worse than surprises. Make sure you have all the facts before beginning. Of course, you cannot know what you don’t know. But the trick is to know the right questions to ask before building. Too often, we focus on the wrong types of questions, such as:

  • Will this application get internal approval?
  • How will person X respond if we take this approach?
  • Does this conform to our branding guidelines?
  • How will this content be managed internally?

Focusing on these kinds of internal-facing questions may get the project approved faster, but it will lead to a far less effective application. In my experience, four particular questions, if neglected, will cause most problems in the development process:

  1. What is the hosting environment?
    When dealing with complex Web applications, knowing the hosting environment is important. Without knowing the environment, you cannot replicate it exactly on your development server, which increases the risk of incompatibilities down the line.
  2. How will users be authenticated?
    Most Web applications require users to identify themselves. Realizing late in the game that this authentication has to happen a particular way or be integrated with some legacy system creates all kinds of headaches. Many companies have a central user-authentication system, and your application will probably have to use it.
  3. How will data be backed up?
    Web applications often hold valuable data, some of which is confidential. This means that having a solid back-up plan is both business-critical and potentially complicated. By considering from the outset how to handle back-ups, you keep this from becoming a serious problem later in the development process.
  4. Is there any legacy data?
    Many new applications will replace existing systems that contain a lot of legacy data. Knowing exactly what this data is and having a plan in place to migrate it to the new system is important.

Learn From Your Mistakes Link

Every Web application presents unique challenges. Over time, though, you learn from your mistakes and discover the key issues. Whether it is focusing on users’ needs, keeping things simple or asking the right questions, these lessons will be invaluable going forward.

However, there is also an opportunity to learn from one another. Unfortunately, many development teams toil away in isolation within large organizations. Articles like this should stimulate discussion and encourage us to share our experiences — both good and bad — of working on these little-heard-of Web apps.

I hope you will take the time to share your experiences in the comments, so that we can come up with new best practice for developing Web applications in our businesses.

(al) (il)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7

↑ Back to top Tweet itShare on Facebook

Paul Boag is the author of The User Experience Revolution and a leader in digital strategy with over 20 years experience. Through consultancy, speaking, writing, training and mentoring he passionately promotes digital best practice.

  1. 1

    Hrishikesh Choudhari

    August 11, 2011 6:08 am

    Very valid points.

    Also if you are a freelancer or someone who takes on a lot of clients, making sure that you have just 1 person to talk to makes a world of difference in your client relations. Often clients have more than a couple of guys to whom you have to talk to, and sometimes they dont talk among themselves.

    Just my two cents, on making the development process more easier.

    • 2

      Piotrek Okoński

      August 15, 2011 7:14 am

      Absolutely valid point. So annoying when you do what boss tells you and then designer complains to you because he doesn’t want to argue with his employer…

  2. 3

    I really enjoyed your article. I agree with everything you said. I would add a product unified vision is also essential. All the stakeholders must agree as to what is being built.

    • 4

      Thomas van der Ploeg

      August 11, 2011 2:56 pm

      Totally agree, a unified vision is very beneficial, both in terms of expectations and the overall progression. Also, I firmly believe its one of the most difficult things to come around. Especially when working in multidisciplinary environments

  3. 5

    Great write-up! Just the thing to get me going this morning on a shiny new project that is really centered around management and internal goals/metrics. Thanks for posting.

  4. 6

    Do you think that your KPI’s should be based around the user tasks generally if that is what you are striving to improve, or perhaps exploding it back out from the task to their work?

    For example, if it’s say a blog system, the work is to write content and publish.
    The system’s task is to publish the content, but does the app improve the total work?

    …. I think that made sense..

    • 7

      I think I understand where you’re coming from. In the particular example you give actually the key performance indicator is nothing to do with publishing content. You need to ask yourself why you are posting in the 1st place. For example if the blog exists to demonstrate your expertise and therefore generate more sales enquiries, the key performance indicator is actually how many people complete the contact us form.

      In other words the KPI should be associated with business objectives not the user task being completed.

  5. 8

    Bart Grootveld

    August 11, 2011 9:21 am

    Interesting read, thanks a lot.

  6. 10

    “Don’t react too quickly to these suggestions. Daniel Burka once told me from his time at Digg that they allow at least two weeks before reacting to user feedback.”

    Yeah and how did that work out for them? Digg is certainly not as popular as it once was.

    I agree in not overreacting to user feedback, but don’t use a bad example to prove a great point. But you probably won’t let that sink in for another two weeks or so.

    • 11

      Wow, a smartass on the internet, imagine that. Perhaps you should use those 2 weeks to write something better then what Paul has taken the time to share with us. That way, when you feel the need to make a snarky comment, you can follow it up with “how it should be done”.

    • 12

      I don’t think that is Daniel’s fault. The decline of happened after Daniel left.

  7. 13

    Always have good stuff to say Paul! I love the “ask the right…” section. So true!

  8. 14

    Thanks for sharing great knowledge. All of the article was indeed useful

  9. 15

    Ejaz Siddiqui

    August 11, 2011 12:13 pm

    Paul, you always give us new and very valuable thoughts. Keep up the good work.

  10. 16

    Great Article, The Best Words I found is “Learn From Your Mistakes” part. I agree with a content of this part. Thanks Paul :)

  11. 17

    While in principle your statement is correct in the section “Sometimes Technology Is Not the Answer”, this is somewhat wishful thinking that you will be able to sale this though.

    Often when selling an application it will need to go through a tender stage. This tender is likely to comprise primarily of a set of feature checkboxes. If your product does not have a specific feature then it will not be considered, even if in productivity terms it is the one app to rule them all.

    The company I currently work for creates Library Management Software. Almost every single tender request states “Must support Z39.50”. Of course in order to sell the product we created Z39.50 import/export facilities, however, the Z39.50 module is used by 2 customers, thousands of customers requested it, but practically no one uses it.

    I do not believe those thousands of sales would have occurred without the feature though, other software would have been selected instead…

    • 18

      I entirely see where you’re coming from an experienced very similar problems with the large higher education websites we produce. However we have discovered that actively challenging the client brief at the tender stage can be a great way to separate yourself from the pack. As long as you can put forward a good argument for taking a different route we generally find that the client is open to such thinking. To be frank if they are not willing to listen to our opinions and I’m not entirely sure we want to be working for them!

  12. 19

    I like it, buts its very basic

  13. 20

    Its a very well written article but I would beg to disagree on some points. e.g.
    Rather than focusing on Hosting environment you should focus on User’s environment (Browser, OS, PC, User Hardware etc).

    For a complex application, You can easily create a hosting environment similar to that of your development environment unless you are on a very tight budget. But this may increase development cost and ultimately cost of the project.

    You may have control over hosting environment but you would not have any control over user’s environment.

    • 21

      I don’t think it is an either/or choice. You are right I should have talked about the users environment but I do not think that precludes the need to consider hosting.

      • 22

        Ejaz Siddiqui

        August 12, 2011 9:06 am

        Both environments should be discussed at the start of the project.

  14. 23

    Useful, would like to +1, please can you add a Google button?

  15. 24

    Very good post, useful for both, client and developer! Thanks.

  16. 25

    WICKED article mate!
    This actually popped a few workflow changes on the fly.

    Thanks much!

  17. 26

    Before you all jump in and start following these generic truisms, please consider reading my reply to this blog post. It wasn’t suitable for a comment.

    I kindly disagree with most things King Paul has uttered here.


  18. 27


    Quick question…

    Assuming the client listens to your advice and monitors the appropriate KPIs etc…do you build into your initial cost the necessary changes that will have to be made after testing has been done?

    Although you create the expectation that they will have to monitor/test/expand I feel like this is where projects can fall into the ether.

  19. 28

    “Many of the suggestions made by project stakeholders (not users) revolve around management issues, such as reporting, workflow and monitoring … But I usually wonder whether it would be easier just to tell content providers not to publish a document before it’s checked by someone else. Does this really need a technical solution when a simple policy would do the job?”

    Amen Brother!

  20. 29

    Good article.
    The best advise I found was the Getting Real book from 37Signals.

  21. 30

    Gordon McLachlan

    August 14, 2011 2:44 am

    Great article, Paul. I think it’s really easy to get carried away with technology and produce apps that don’t actually solve the business needs of the client. Likewise, it’s very easy to take feedback from random strangers too personally and end up falling over backwards to alter usability to suit someone you’ve never met on Facebook!

  22. 31

    very good articels. it’s inspiration to me to know that “Sometimes Technology Is Not the Answer” ;-)….i like it!

  23. 32

    I find articles like these highly patronising. I’m kind of disappointed if I’m honest that somebody who is such a so called “expert” would patronise the design community with statements such “Learn from your mistakes”. Jeez Paul, how old am I, 12?

  24. 33

    Blah…Blah…Blah… All I hear is noise from this crappy post. Focus on users not features, learn from your mistakes. Pal, we’re not a bunch of children, spend any amount of time on development you’ll pick these up very quickly….

    We’re not children, take a cue from Head First Software Development!

  25. 34


    August 16, 2011 5:58 am

    yes adam “We’re not children, take a cue from Head First Software Development!”

  26. 35

    the post sounds more like common sense than anything else

  27. 37

    very good articels..

  28. 38

    Am looking for Webinar Software that is economically feasible and user-friendly for Non-profits. Any suggestions? Thank you.

  29. 39

    Focus on “what” first and foremost. How comes later, with a price tag.

    More than ever I see feature and scope add-ons from clients that don’t know what they want. I think todays more flexible and iterative development methods are partly responsible but, OTOH, the previous waterfall-based methods lead to endless requirements definition before the first line of code.

    The shared client/builder vision of what the project will look like when it is done has always been the elusive designer goal. This is a good Q&A list and path to follow but I don’t know of any reliable silver bullets. A strong deadline or small budget are two conditions I’ve found conducive to keeping the scope small and focused.

    Nice article, as always, Paul.

  30. 40

    Douglas Garratt

    August 22, 2011 3:10 am

    Thanks will def take this article onboard we are about to make a web app for so this has been a great read. Thanks for sharing, will be checking this site daily now I think. Thanks again!

  31. 41

    Cezary Tomczyk

    September 6, 2011 1:19 pm

    “I usually wonder whether it would be easier just to tell content providers not to publish a document before it’s checked by someone else. Does this really need a technical solution when a simple policy would do the job?”

    Simple policy sometimes not enough. You can not trust 100% to employees. The requirement to approve the content is greater guarantee the accuracy of content.

  32. 42

    Apps are turning into essential tools for businesses to communicate with their clients. I suggest reading Create iPhone Apps That Rock: A Guide for Non-Technical Folks before you make an app. It help you plan , execute, and market your app.

  33. 43

    Apps are great!!!! I have a new andriod phone and I can’t stop downloading applications from the market.
    I love apps. I feel they are an essential tool for gizmos like phones and the ipad family……..
    Apps rule……


↑ Back to top