How to avoid the most common mistake most architects make when designing solutions

By on January 16, 2014 in Software Design

So what is one of the most common mistakes that most software developers and architects make? Very simply, developers and architects rarely consider the user interface when designing solutions. That’s it, you can stop reading now if you are part of the 1% that don’t make this mistake.  However, if you are part of the 99% that don’t believe the user interface is architecturally significant, then give me a few minutes to change your mind.

To begin, let’s come to terms with a definition of software architecture. The term is often a topic for debate among architects but since it isn’t the topic for this article, I would like to offer the definition presented in the book Software Engineering in Practice (3rd Edition).  For me this book is a must read for both new and experienced architects.  I have a copy of both the second and third edition and often refer back to it.  Software Engineering in Practice defines software architecture as:

“The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.”

I really like this definition because it’s concise; it clearly identifies what we are attempting to achieve with the architecture. We are attempting to define a set of structures that communicates the goals of the solution.

The text further breaks down the definition by stating.

“A structure is simply a set of elements held together by a relation.”

So the architecture has a singular task: to identify the structures, their elements, and the relationships between them.

The text goes further stating:

“A structure is architectural if it supports reasoning about the system and the system’s properties.”

This means that the architecture need only contain the portions of the system that are architecturally significant.  The architect must decide which structures should be included and to what degree.

To take it one step closer to implementation I would add:

A solutions architecture is a blueprint that guides and shapes the implementation with regard to the pieces that are the most difficult and costly to change.

So if we can all agree, if only for a moment, that these four statements are a fairly accurate representation of software architecture, then I again pose to you this question.  Should software architects be concerned with user interface design?

To answer this question let’s use our agreed upon definition of software architecture as evaluation criteria.

  1. Is the user interface a structure needed to reason about the system? I would say no it isn’t given our definition of a structure is “a set of elements held together by a relation”.
  2. Does the user interface represent the goals of the solution? Well, no, not really.
  3. Does the user interface support reasoning about the system and the system’s properties? Again, no, not really.
  4. Is the user interface a blueprint that guides and shapes the implementation with regard to the pieces that are the most difficult and costly to change?  Again, no, or does it?

So if the user interface does not meet most of our criteria for software architecture, why should it be a concern of the software architect? Well my friends that is the point if this article.

One of the paramount goals of any architectural design effort is to mitigate risk to the project. Architects attempt to work out the complexities on paper first before considerable cost is sunk into the development effort.  This is the reason why architect’s focus on the most difficult and costly pieces of the solution; these are the things that are the most risky to a projects success, they are architecturally significant.  I teach this very thing in my developer to architect course and I stand by it now.  So with that said, is the user interface a risky part of the solution? Is it architecturally significant?

I believe the answer is yes. I would even go so far as to say that the user interface is one of the most important aspect of the solution.  It should be considered a first class citizen when designing a solution and here is why.

Our customers always judged our solutions by what they look like first.  There are other factors but the most highly weighted criteria to our customer is the user interface.  Performance is important but only secondarily so. If you show a poorly designed user interface, even with the best back-end design, your customers will naturally assume the rest of your application is poorly designed.  I would even go as far as saying that if you were to offer your customer a choice of a flashy, well designed user interface with a horribly designed back-end versus a well-designed solution with a lackluster UI, they would pick the flashy interface  every time.  Now I don’t have any statistics to back this up, but I do have more than 20 years’ experience delivering software solutions and can tell you this is indeed a fact and here is why.

The user interface is all our customers understand, they don’t care about the rest of the solution.  No matter how great the design is, your customer’s perception of the solution is based on what they see and how they interact with it.  Let me say that again because it is that important.  No matter how great a solution you have designed, if it looks bad, your customers will think it is poorly designed.  This isn’t fair, but it is a reality that we must all come to terms with. Perception is reality, do not underestimate this.   The user interface is what our end users can see, what they interact with, it is one of the few things that our customers understand and can use to evaluate our solution. The 80% of the solution that makes it function is just plumbing to them. They know it’s there but just expect it to work and do not put the same weight on it that they do the 20% they can see. It’s more of a pass or fail evaluation for our back-end designs, if it works we pass, if not then we fail, there are no points for creativity and artistry.

So if a user evaluates our entire solution based on its user interface, then doesn’t it add considerable risk to your project if you don’t consider it in your design? Doesn’t this make it architecturally significant?  I believe the answer to both questions is a resounding yes.  Now to be clear, I am not saying that we should abandon common design concerns for user interface design.  I am saying that the user interface should be considered architecturally significant, and as such, should be considered in your architectural design.

I realize that this is probably not a groundbreaking realization for many of you.  But for those of you shaking your head saying, I know this already Chris, you aren’t telling me anything new; are you including user interface design in your solution design?  Or are you doing it as an afterthought? Way after you have completed your architectural design.   While many of us know that user interface design is critical, we continue to make the same mistake over and over by not including it in our design effort.

Why is it that we rarely considered UI design when we design our solutions?

I think the answer is that most developers and architects just aren’t that good at user interface design, myself included.  And what do we do when we have to complete something we aren’t good at? We procrastinate of course, we ignore the problem; we save it for last and then inevitably are forced to deal with it as an afterthought. I am just as guilty of this as the rest of you.   I have been on many development teams over the course of my career and can only remember having using interface experts on one.  For some reason we think that we can design a solution without any consideration for the user interface.  So what can we do about this?

Well, quite obviously, we should include the user interface when designing our solutions.   When you assemble your teams, lobby for a user interface expert.  They aren’t that expensive an addition to your team, compared to developers anyway, and a good user interface designer is worth their weight in gold.  Designers are an incredible asset to any development team; they think much differently than architects and developers and will help push you and your team to make better solutions.  If you aren’t able to get a designer assigned to your team then look to your marketing department. Quite often you will find excellent designers that may be willing to help.  If neither of these are options then it’s up to you.

I have found that the best way to design a user interface is to create wire frames that depict what the application will look like when complete.  Never show a working prototype to you end users. When a user sees a wire-frame they understand that making it function will take effort.    When a user sees a working prototype they believe that creating the rest of the solution is easy. They won’t understand why everything else is taking so long and may become impatient or even unhappy.  Remember our customers do not understand what it takes to create even a moderately complex solution.  They think that once he UI is complete that the rest should take no time at all.

Lastly, provide a few choices for them to review.  Our customers like to feel like they are part of the team. They want to collaborate with the technical team and help contribute to the solution.  Encourage this; it not only helps you build a better solution, it creates happy customers.  And happy customers that have a sense of ownership in a solution often turn out to be your biggest fans.

So hopefully I have given you a few reasons to include the user interface in your next architectural design.  If I have then let me know how it works out for you.

Struggling with a difficult architectural challenge?  I am always looking for good article ideas so shoot me an email via the contact form on my blog.

Tags: ,


If you enjoyed this article, subscribe now to receive more just like it.

Comments are closed.