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:
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.
For more information on this "budget" approach to usability, I recommend Steve Krug's latest book Rocket Surgery Made Easy.
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…
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 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. Allow users time to adjust to the application before making changes.
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.
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.
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:
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)
© Paul Boag for Smashing Magazine, 2011.
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:
- Focus on user tasks and not features,
- Don't try to solve everything and
- Ask the right questions early on.
Focus On User Tasks, Not Features
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.
Take a Step Back
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
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.For more information on this "budget" approach to usability, I recommend Steve Krug's latest book Rocket Surgery Made Easy.
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
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
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
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 Burka 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.
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
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
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
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?
- 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. - 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. - 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. - 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
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)
© Paul Boag for Smashing Magazine, 2011.
No comments:
Post a Comment