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:
Let’s begin by looking at user tasks:
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.
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.
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.
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.
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…
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.
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.
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.
But that is not an excuse for ignoring the opinions of users. In fact, you should carefully gather as much feedback as you can.
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.
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:
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:
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:
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.