Feature Design Best Practices

Feature Design Best Practices

Feature Design Best Practices

When adding a new feature to an application, it is important to fully design the feature and keep the user experience in mind.

A developer could run into an issue where the feature they envisioned was created, but didn’t meet the end user’s expectations or didn’t solve for the specific need that prompted the feature request. An improperly designed feature could exceed the quoted time, increase the risk of an unstable production site, or negatively impact the user experience.

Depending on how involved you are in the design and who the decision maker is, some of the questions to consider may be irrelevant. Still read through the steps since others may still help identify issues early on. In order to save the most time and identify any issues in the design early on, you can use the below steps and best practices.

Starting Questions

At the beginning stages of the feature design, keep in mind two important questions:

  1. What is the need you want to address?
  2. How will you solve this?

The Need

Your first question should be looking at the problem first from a user perspective, but then dig down to the source of the need. For example, if the problem is that users of an eCommerce site often forget the products they want to purchase or have trouble finding the ones they want, the problem could simply be the lack of a “My Lists” or “Wish List” feature. However, if after developing a “My Lists” feature, it would be unfortunate to find the actual problem was non-searchable product descriptions.

The Solution

Once you have identified the need, you can start to think about the solution. Again, start from a user perspective (“hey if there were a button for that it would be real helpful!”) and then work backwards to think how the proposed user solution would work. Right now, keep your approach high-level. First we want to make sure it passes all requirements to qualify as a solution before any time is wasted designing it.


When finding a solution, it is good to think about it in the context of the rest of the application. If this feature will have an error message and all other error messages on the site are pop-ups, then this one should also display an error message in a pop-up window. Even if an application is created by a handful of developers, for consistency it should appear as though it was designed and developed by a coordinated team or a single person. If you do not know the application well enough to know what would be consistent behavior, this step may require some research.

Another aspect of consistency is remaining consist with other related applications. If the application is an eCommerce site, and the proposed feature is “My Lists” or “Wish Lists” many eCommerce sites already offer this feature. If your users are already familiar with this feature, why make them learn something new? Without having to completely reinvent the wheel you may some some development time and prevent building a feature that is not intuitive and a pain to learn.

The Users

Who are the intended users of this feature? When a feature is designed by someone who is very familiar with the whole application it might be easy to lose sight of the target users. If the feature is too complicated, could a disclaimer or help text be added? Does it require a change to the proposed solution? Will everyone be able to see/use this feature the way you described or should functionality change depending on who is looking at it?

Integration with the Application

Although we are keeping things high level at this point, if there are relevant other features this one needs to integrate with, it is a good idea to mention it early on. If the feature is a useful tool on the shopping cart, but not everyone has access to the shopping cart page, that might change the plan to put this useful tool elsewhere or re-evaluate who the users of this useful tool will be.

If you are the developer and not involved in any decision making, this may be the most relevant starting question to you. The developer is often the most familiar with the rest of the application and will be able to shut down or suggest modifications to a proposed solution that the decision makers may not have thought of.

Another reason to think about the integration to the existing application is if there are pieces already available in the application that can be reused. This would bring down the development time and make the solution very desirable if it requires little to no changes. Hopefully the rest of the application was built in a way that allows for easy re-use.


It is a good idea to think of several different solutions. Often the first idea is not the best and it is good to have options. At the end of the design, we will be able to lay out all options and present the pros and cons of each including time estimates. This will help pick a balanced solution that has the least amount of risk.

Planning Solutions

At this point, you should have at least a couple of solutions that have made it past the starting questions. After you have some options for your solution, you can begin to plan them out. This step is best done while looking at the application.

Front-End Planning

Again, this is best to start from a user perspective. Is the solution just adding a button? Will the button look like all other buttons or should it have a label nearby explaining what the button will do? These are more in-depth questions you’ll have to think about when planning each solution. Some more complex solutions spanning multiple pages may be helped by mock-ups or maps. Remember to think about all possible use cases.

By the end of this planning stage you should know what the solution looks like to the user.

Back-End Planning

Now, take the front-end plan and at each screen that will be changed, write down what will need to be changed to achieve that. You should have a list of Web Pages, WebParts, and maybe a note to change some CSS.

Once you have decided how the feature will change the look of the site, there should be steps in the mock-ups or maps that sound like “then do the thing”. These steps need to be fully designed. If you need help visualizing the feature, a good idea is to open all the WebParts and Processes and get into the mindset of building the feature. If you were going to work on this right now, what would you add or edit or delete? Write down all the steps you would do. If you still have multiple solutions at this point, keep it more high level so you don’t waste time on the fine details of a solution that may not get approved.

If the feature involves anything new (a new process, database table, etc) you can also write the proposed name in your notes. If you are the most familiar with the application, you should already be aware of the naming convention used. If you are not, you can take a moment to see if custom tables or tables related to the feature are using a naming convention. If they are, following this to be consistent would ensure a new developer, not familiar with the application, can more easily find associated pieces.

By the end you should have a good set of instructions for yourself or someone else to follow if this solution gets approved.

Quoting Time

Adding Time Estimates

During the previous step you should have created a list of Web Page, WebPart and Process Ids that will be changed. Go through all your listed changes and estimate how long it would take you to do just that portion. Remember that for that one Process change to be done, you will include time to promote and test. It is better to overestimate than underestimate.


At this point, you will want to break down the solution into a few categories. If many processes require a change for the solution, sum the estimates from all the process changes so you can see at a summary level how much time you would spend changing processes for this solution.

Remember to add time for testing. This is considered time for User Acceptance Testing (UAT) or testing from a user perspective and reviewing the feature as a whole.

Feature Categories

  1. UI Changes
  1. WebParts
  2. Web Pages
  3. CSS
  1. Processes
  2. Workflows
  3. Files
  4. Javascript Changes
  5. Database Changes
  6. Testing


Here is an example of a quote broken down by these categories:

UI Changes

24 hours

Process Changes

16 hours

Db Changes

2 hours

File Changes

5 hours


5 hours

Here are the notes that were used to create that summary:

WebPart Changes

  • WPT554 Promotions: Add a Promotion
  • Add new option for Required Items with multiple sets in drop down
  • Add hover over text to explain how this drop down works
  • WPT554 Promotions: Add a Promotion (Button Process)
  • Add Validation for new option
  • Change reference from old column name to new column name and add new references for multiple required sets of items.
  • WPT555 Promotions: Work with Promotions
  • Change text of hyperlink to read “View Eligible/Required Items”
  • Resize pop up window for the hyperlink to be larger to show new columns
  • WPT181 Promotions: View Eligible Items
  • Change webpart name to View Eligible/Required Items
  • Display both categories now
  • Add columns to the list section for new columns in Db: Required1, Required2, etc.

Process Changes

  • PRC478 Download Promo Items
  • PRC478 Recalculate Promo Eligibility
  • New Process to determine Required Eligibility for Promo Items

Database Changes

  • EC_PromotionItems
  • Add new columns: Required2, Required3, Required4, Required5
  • Rename old column Required to Required1
  • New Table: EC_PromotionRequiredLogic
  • Columns in Table: PromotionId, RequiredMinOrderValue, RequiredMinQty, AndOrLogic, RequiredSet
  • Primary Key: PromotionId, RequiredSet
  • Required Set is an Int
  • EC_Promotion
  • Add new column: RequiredSetsUsed
  • Sync Entities, Restart Enterprise Server

File Changes

  • Change file “EligibleItemsListTemplate.csv” in all environments

Pros and Cons

At any point in the process multiple solutions could dwindle to one and at this step would not be completed as part of the process. However, if there are still several options and you want to present some summaries to a decision maker to approve a single solution, a Pros and Cons list can be very helpful.

Solution 1



Using the existing design. The pieces needed to create this already exist. Minimal development time, mostly test.

Complicated design will require more development time now and more time in the future if improvements are made to the feature or related features that integrate with it.

Matches user’s expectations for the feature. They already use a very similar feature. Minimal changes mean no training needed.

Currently works, but will be messy in the database. Without clean up or proper documentation it will not be intuitive for future developers.

Easy to do now

Hard to Maintain

Solution 2



A redesign will ensure it is built the most efficient way

Takes more development time

Change to build it cleanly so it is easy to integrate with, for future developers to work on and maintain.

Redesigning feature may change how it looks and will be strange to the users.

Cleaner Design, Easier for future

Harder for now