CodePartners - Software Development - Dallas, Texas Software Development - Sage Accpac Customization - SageCRM Customization
Login
pay invoice online  |  remote assistance  |  
  • INTERNET APPLICATION DEVELOPMENT

    • Services
      • Web Application Development
      • Mobile Applications
      • Integration Solutions
      • Staff Augmentation
    • Technologies
    • How we work
    • About us
    • Success stories
    • Blog
  • MID MARKET ERP DEVELOPMENT

    • Intacct
    • Sage CRM
    • Sage
    • Sage Component Catalog
    • How We Work
    • About Us
    • Success Stories
    • Blog

Blog

CodePartners Blog

rss


How Flexible Should a System Be?

SHARE THIS
Facebook twitter linkedin Print Print
Print Email

by Derek Du

Flexibility has a real cost

 

It is common for people to ask UI designers to design a system as flexible as possible. People believe that it is always better for something to be flexible. They think the more flexible the system is, the better the overall experience of the system. However, this is not always true. When we say this design is more flexible than the other one, we are saying that this design can handle more use cases, conditions, or scenarios. In other words, it performs more functions than a less flexible system. But, because it can do more, it often is more complex, which in turn decreases the usability of the system.

A great example from Universal Principles of Design about this tradeoff between flexibility and usability is the comparison between a Swiss Army Knife and corresponding individual tools. A Swiss Army Knife has many attached tools that increase its flexibility, but to put all those tools in one tool, it sacrifices usability – users spend more time looking for the needed tool and then carefully digging out the tool. The complexity also has impacts on the Swiss Army Knife’s size and shape, which results in a less comfortable handle than corresponding individual tools. 

This diagram shows that the more flexible a UI is, the more it costs.

 

Why flexible?

 

Knowing this relationship, it seems that flexibility only decreases usability -- what benefit does it bring to the table? In my opinion, perhaps it is only beneficial to build a system flexible when you can’t anticipate future uses of the system. The flexibility helps accommodate any unexpected future uses, so the system does not need to be modified as much as an inflexible system. On the other hand, if you clearly anticipate the need, you don’t need flexibility. Why would you add features you know you will not need? There is a cost for keeping unneeded things, i.e. higher maintenance, more complex structure that makes changes difficult, etc. You aren’t gonna need it (YAGNI) principle also presents several reasons for not adding features until deemed necessary.

·         The time spent is taken from adding, testing, or improving the necessary functionality

·         The new features must be debugged, documented, and supported

·         Any new feature imposes constraints on what can be done in the future, so an unnecessary feature may preclude needed features from being added in the future

About building a flexible system vs. a specialized system, a great example from Universal Principles of Design is a comparison between a personal computer and a video game console. We use computer to do all sort of things and can’t anticipate the future uses of the computer, thus the flexibility of it. Game consoles are built only for playing games. It is a specialized system that does not need the same level of flexibility as a PC because we can fully anticipate the uses of it.   

How flexible?

 

Knowing these key factors, when approaching the problem of how flexible a system should be, we can tackle the problem via the following practices:

1) Clearly define the uses of the system

Only when we clearly define the uses, can we know whether flexibility is needed. Requirement analysis itself is a topic that will require a whole series of posts, but knowing that this has to be done is critical.

2) Compare levels of flexibility with the cost in mind

As mentioned previously, increased flexibility has a cost for usability and development effort. So we have to look at all factors together. What I often do is put design candidates with different levels of flexibility side by side. I play with the different user interfaces just as if I am a user so I actually feel the pros and cons of each design.

An example involves setup screen for sending system notification emails, such as error reports. Should I provide the flexibility to allow the From Address and Sender Name to be edited?

Things like From Address and Sender Name, once are set up, may never change. Allowing these to be changed like in the first design below introduces more user errors and longer setup time, thus reduces usability. The second design does not allow these to be changed, but could cause some confusions - why are these read-only? Do I need a higher permission level to edit them? The third design allows these to be editable but also provides default/suggested values, which increases the flexibility without reducing much of the usability. By comparing the three designs, a decision can be made quickly.

Aside from usability cost, we also have to deal with the cost of time and money. Consider the same email notification designs. If the first design cost $1, the second $100, and the third $1,000, the first design is mostly going to be favored. Development cost like this can have a great impact on the decision. What I often do is presenting all the cost factors to the stakeholders and work out a decision together.

3) Stop when you have to

During the system design, we will apply the first two steps and create designs with high flexibility and low cost. When design phase is over, we hand it over to development team. Whatever level of flexibility we have in design at that point is the level the system will have. Every project has a time constraint. Even if you don’t want, it is going to decide the level of flexibility for you.

I covered a basic introduction to flexibility and a few practices we apply to our projects. There have been numerous discussions on software flexibility out there. Many of them are around flexibility on software architecture, but the basis is still the same - flexibility has a cost and it is beneficial when we can’t anticipate future uses. I hope that knowing about these basics is helpful!




Comments are closed.
On February 6, 2015 in Development, Web Development [Post:by]
Tagged With: usability, Flexibility, system design, UI design, UX design / 2882 Views

Search

Categories

  • General (166) rss
  • Development (158) rss
  • Success Stories (40) rss
  • Products (29) rss
  • Uncategorized (18) rss
  • BTerrell Group (5) rss
  • Project Management (22) rss
  • Web Development (57) rss
  • Web application (33) rss
  • Integration (19) rss
  • Mobile Development (7) rss

Archives

  • 2015
    • January (5)
    • February (7)
    • March (6)
    • April (5)
    • May (2)
  • 2014
    • January (13)
    • February (12)
    • March (13)
    • April (12)
    • May (11)
    • June (12)
    • July (11)
    • August (13)
    • September (10)
    • October (8)
    • November (6)
    • December (4)
  • 2013
    • April (73)
    • May (22)
    • June (20)
    • July (20)
    • August (22)
    • September (19)
    • October (13)
    • November (12)
    • December (7)

Tags

.NET Accpac app development application customization application development automation Azure C# cloud components Crystal Reports customization development ERP general ledger HTML5 Intacct Intacct Platform Services integration JQuery load balancer mass update mobile development OCR Order Entry outsourcing PO pricing product development project management REST Sage 300 ERP Sage CRM software integration trigger user interface Visual Studio web application web development website development Workforce Go! .NET ACA accpac Ajax Amazon AP invoices application development Arxis ASP.NET automation Axure BTerrell Group C# Cloud computing CodePartners Constant Contact credit card processing CRM crystal reports custom software Customer Service Customization Delete team project design phase Development doc-link DRILLDWNLK ERP event Excel GLAFS Intacct Intacct Advantage Intacct Platform Services Integration Java script JavaScript jQuery Kerr Consulting LinkedIn Microsoft MSSQL Offshoring outsourcing payroll PCI compliance PCI-DSS Pivot PJC project management sage Sage 300 Sage 300 ERP Sage Accpac ERP Sage CRM Smart Rule social media software testing SQL SQL Query SQL Server staff augmentation sub-ledger success success story TFS Trouble shooting UI design Visual Studio WCF Web API web application web design web development Webinar website Windows Windows Azure XML
Email this article from Codepartners.com
Separate multiple addresses with commas(,)
To: *   Copy me
Subject:
From: *
Message:
ABOUT US / CONTACT US / NEWS & EVENTS
CodePartners / 17250 Dallas Parkway, Ste. 225 / Dallas, Texas 75248 / Phone: 214-647-2611 / Toll Free: 866-647-2611 / Fax: 214-647-2612 / info@codepartners.com
© 2006 - 2015 codepartners.com All Rights Reserved.