Why Users Demand a Top-Notch Interface These Days

How UI and usability are changing the focus of software development.

Let's take a trip down memory lane. I knew years ago I wanted to be involved in UI design. Back at university I enjoyed making 'pretty interfaces', and for some reason had an inexplicable ability to retain information about design patterns. Sometimes my aptitude for UI design gave people the impression that it came easy to me, but like most people who've gotten good at something, there's a lot of hard work behind it all. The truth of the matter is that the skills had to be refined with long hours of research, reading, experimentation, and most importantly doing interface design.

By far, experience has been my biggest teacher. I've learned that it's 'not done until it's done'; if a UI design has to go though 14 revisions - so be it (and this has happened to me!). If something can be done with 2 clicks instead of 3, than that's my goal (than, I start thinking about how it can be done with just 1 click). I could tell years ago that companies would one day be scrambling for people with Interaction Design (IxD) skills. When software development began shifting away from desktop applications and towards web-based systems, it was clear a fundamental change was on its way (in terms of how we use computers). A number of other trends gave strength to this revolution, including; pervasive broadband uptake, mobile/wireless broadband becoming reasonably priced, and Apple consistently changing peoples' technology-use behavior.

One of the driving forces behind this fundamental shift was surely everyone getting access to low-cost 'always on' broadband. Without this, it simply could not have happened. If you've had the pleasure of reading Thomas Friedman's The World Is Flat, you'll see that the reason we ended up with pervasive broadband was partly due to the optic fiber 'fire sale' which took place after the dot com crash. In a nutshell; what happened was businesses invested heavily in expensive optic fiber cable. Then they went broke and were forced to sell their assets. Other companies came along and snapped up all this cheap cable at a bargain price (which in turn, they passed on the savings to customers).

Technology wasn't the only catalyst for change. Another big factor was the shift towards the Application Service Provider revenue model. Finally the industry had found a way to stop software piracy dead in its tracks (i.e. host the software online and get users to pay a subscription fee for access to the service).

Personally, I think that thanks to companies like Microsoft, Google, and Apple the average Internet user has become spoiled rotten in terms of the UI and user experience they expect. The bar has been set very high, but people don't appreciate that Google and others pour millions of dollars into their interface design efforts. People now expect this level of quality from all their Internet enabled software. This is probably a good thing since it forces companies to produce software the way it should be; designed for normal human beings, self-evident (i.e. no manual required), and suitable for a broad audience.

So why is it that Internet users demand such high standards from their online software today? I'd say it's because 'doing things online' has become a cultural norm, or even a borderline necessity. Gone are the days when paying bills online or booking airline tickets was something only nerds did. Would you not look at a colleague sideways if they said "I'm just popping down to the post office to pay a bill" (as opposed to paying it online)? The reality is people still are clinging to the old way of doing things (e.g. people still physically go down to the bank).

The next stage of 'doing things online' could coincide with the dissolution of the traditional outlets of commerce. For instance; there are ISPs now who expect you to sign-up online, and they only accept payment via automated electronic mechanisms (e.g. monthly direct debit). Is it so far-fetched to think that in the not too distant future we will be voting in elections via a website?

The media has also played a pivotal role in this transition. Notice how every poster at a bus stop these days has the Facebook and Twitter logo on it? Mainstream media's ability to shape social habits shouldn't be underestimated.



As more of the traditional physical outlets of commerce disappear in favor of their lower-cost online variants, it's as though the general public is being forced to do things online. If that really is the case, than the number of non-tech savvy users will skyrocket. This is what causes the demand for high quality interfaces, because large numbers of people who wouldn't normally do things online are beginning to convert. The companies that can deliver ease of use will no doubt prosper whilst those slow adapt will fall by the wayside.

Subscribe to RSS Feed.

Conducting a Usability Review

An approach for unearthing usability issues in web-based systems.

You don't see the spots before your eyes until they are there.

- Chinese proverb

These days people expect so much from a user interface. Thanks to companies like Google, Microsoft, 37Signals and many others, web surfers have come to expect a world-class user experience no matter what application they use. People don't care if a multi-million dollar budget is available or not, the 'big boys' have spoiled them rotten and exceptions are high. This is bad news if you don't have a skilled UI person on your development team (or if you don't have the budget to hire someone for a short-term contract).

The consequence of sub-standard usability on a website may be subtle. For instance; if your online shop crashes when a person adds an item to their basket, they may be inclined to tell you about it. But if it’s something seemingly innocuous like locating contact details inside your 'About Us' page (instead of within a dedicated contact page), there's a good chance visitors wont even be able to find contact details to let you know something's gone wrong.

This is where a usability review comes in (or usability audit if you prefer). Conducting a usability review requires a certain kind of knowledge and expertise not common to all IT professionals. The same way a person may have a knack for SEO or picking up new programming languages, such is the nature of UI design. The intuitive aspects of usability and HCI analysis, like any other skill, can be learned, but not everyone is inclined to do so. Therefore, some kind of guiding template would be useful to those not willing to commit vast amounts of time to mastering the discipline. A usability review can provide just this kind of structure.

What sort of project would benefit from a usability review? Pretty much any system which has been developed without the direct input of a usability expert from the start. If a usability specialist has been engaged from the onset of the project, chances are good that many usability best-practices have already been implemented. In this situation, you'd be better off spending time conducting usability testing instead of investing time in a usability review (e.g. watching end-users directly interact with the system).

So what does a usability review look like? The structure is quite simple; it’s just a Word document full of bullet points describing two things: what the problem is, and a suggestion for fixing it.

For example:

• Use of ‘click here’ hyperlinks - this is dated and passé (also poor in terms of SEO).
  Fix: remove instances where ‘click here’ is used with hyperlink (e.g. ‘click here for sales enquiries' would become 'make a sales enquiry').

You may wish to create a few sections within the Word document to make it more manageable (e.g. Interface Issues, Visual Communication & Branding, Information Architecture, Error Messages, Content & Language, etc).

The big question of course is; what to look for when conducting your review. This is a tricky question because in truth, the answer is far beyond the scope of a simple blog article like this. That said, I have prepared a basic list of a few common UI errors to keep an eye out for:

• Flag distracting animations as a usability issue (e.g. Flash)
• Show the file size of downloads (e.g. Annual Report PDF - 200 KB)
• Watch for poor typography usage (e.g. small fonts for headings)
• Keep an eye out of misaligned controls and UI elements.
• Review online forms for consistency (e.g. widths of textboxes)
• Be watchful for unintuitive error messages written by programmers
• Is there online help for complicated forms or interactive tasks?
• Should form fields marked as required be optional instead?
• Are required fields obviously marked in some way?
• Can some labels on forms be shortened (e.g. 'Phone' to 'Ph.')
• Should some labels be expanded to become more understandable?
• Are large images used which do nothing other than add load time?
• Are JavaScript pop-ups used for error messages?
• Is a 'No records found' message shown for unsuccessful searches?
• Can a user tell where they are within the website?
• Is the navigation structure unnecessarily deep (>3 levels is bad)?
• Are there graphics anomalies (e.g. overly compressed JPEGs).

How long does a usability review usually take? Unfortunately, the deeper you go into a flawed system, the more problems you're likely to uncover. There is sort of a snowball effect, so you do have to decide a cut-off point; how long you are willing to spend reviewing each screen (e.g. 45 minutes per page, including writing up corrective notes). The number of problems you unearth is also a function of your skill level, if you're good at it, UI issues will jump out the screen at you. Another thing to consider is this; there's no point conducting a usability review unless you've done at least the most basic of QA testing (e.g. checking for broken links, alerts for required fields on forms, cross-browser compatibility, etc).



If you are interested in going further into the realm of usability, I would suggest Steve Krug's book Don't Make Me Think. As far as online resources go, you can't pass up Smashing Magazine (although this is heavily targeted towards graphic designers). There is also Jakob Nielsen's useit.com website and Joel Spolsky's Joel on Software website.

Article Adjunct

• Usability reviews should be done after conducting at least basic/ad-hoc usability testing with a few users.
• What you find during user testing should dictate what issues you address first (before a usability audit).
• As a developer or system architecture working with the software on a daily basis for long periods of time, it becomes easy to miss problems staring you right in the face (i.e. you can't see the forest for the trees).
• If the usability report is expected to be seen by non-technical stake-holders, it's a good idea to include a short summary at the beginning of the document. This would outline the most important findings of the usability audit.
• The suggested fixes contained in the audit should also under-go user testing. It's always possible that the suggested fixes don't solve the problem (or they may even introduce new ones).
• Ideally, the best time to conduct a usability review is early and at multiple stages throughout the SDLC (not just as an after-thought at the end of a project).

- Contributed by Moin Uz Zaman, Senior Usability Specialist

Subscribe to RSS Feed.

Consistency in Web UI Design

How to keep your software's UI consistent when many programmers are working on the project.

In a development team with half a dozen programmers all working on the same project, creating a uniform user interface can be a nightmare. There can be problems ranging from inconsistent use of icons to language (e.g. formal vs. informal). So the question is, what's the best way to achieve a cohesive user experience?

Few would argue the importance of UI design these days, especially since companies like Google and Apple have spoilt users with dazzling almost joy-to-use interfaces. But a functional application is still more important at least initially, you can always pretty things up once your software actually works.

When working as a UI designer, it was my responsibility to create mockups for the application being developed. Once I had created the HTML and image files in Web Expression and Photoshop, all I needed to do was bring them into Visual Studio as Master Pages. This worked out great because the programmers would then come along and add the logic.

This turned out to be an excellent approach since it doesn’t require a style guide or volumes of documentation. It works because just one person was in charge of the UI design. The reality is most companies don’t hire someone specifically for a UI role, although more companies are starting to (compared to a few years ago).

Having worked as an IT project manager for a few years now, I have found there is another approach which works well for ensuring UI consistency. Personally, I don’t put much faith in writing UI guides and expecting programmers to follow them. There’s a few reasons for this: 1) programmers often aren’t good at UI design, 2) it’s a lot to remember, and 3) its counter-productive.

UI style guides slow down programmers because you are expecting them to be good at something which they aren’t geared for; they are good at coding, so let them code.

So what do you get when you let programmers do their thing and just code with no specific guidance on UI? Inconsistencies in the interface. This even happens when you provide programmers with mockups to work from. For example, your mockup might not contain the exact wording for an error message so a programmer, quite rightly, proactively puts one in (e.g. “Invalid input”).

What’s the solution? Easy, you have one person review the entire interface at milestones and log bugs in the issue tracker. These bugs would be marked as UI or low priority. If there’s a script error in the software, it’s obviously more important to fix that first before looking at a UI glitch.

The next question is, who should be doing the interface review? It should be one person only (for consistency sake), and that person should be whoever is the most talented with HCI/UI design.

My point is this, don’t make programmers try and be UI designers. When you log a UI bug, it’s there in the issue tracker, it won’t go away. The programmers will come and fix them when they are good and ready. UI bugs are generally easy to fix so they can act as a good break for a programmer. Imagine a coder has just spent 2 hours debugging a serious data corruption issue. Fixing a few UI bugs would most likely come as a welcome relief.

As far as language or wording in an application goes (e.g. error messages, online help, labels, etc), you wouldn’t necessarily need to log bugs for that. If you are using a string table, or some kind of configuration file like XML, then it’s easy for the UI person to tweak text by directly accessing the configuration store. For example, if you found "login error" in the configuration XML file, you could change that to "the username or password you entered is incorrect".



When things get written down they will be forgotten. This is especially the case when documents get long (e.g. 20+ pages). The problem becomes compounded when you realize that programmers could care less about consistent UI across all the screens of an entire application. Their task lists often say 'Code login screen', not 'Code login screen - and make it look pretty'.

As a side note, I should say I have written a massive UI style guide for an application I designed. It took me almost 2 weeks to write and personally I think it was unnecessary. It was basically a way for programmers to understand how to modify the interface once I finished my contract. As to whether they found the guide useful or not, I don’t know. I think design should be left to designers and coding should be left to programmers, it just makes good business sense.

Subscribe to RSS Feed.

10 Usability Tips for Your Web Applications

Simple tips and techniques for improving the usability of web-based applications

Usability is a quality attribute that assesses how easy user interfaces are to use. The word "usability" also refers to methods for improving ease-of-use during the design process.
- Jakob Nielsen

It’s definitely an exciting time to be part of the software development industry, companies are really starting to embrace usability in a serious way. Not so long ago usability was an after-thought or novelty, a specialty field only trendy types took interest in. Now, any developer worth his salt appreciates the significance of usability. This is a good thing for users since they are the main beneficiaries of the trend (i.e. they are getting more usable, or better, software). Obviously, those companies investing in usability knowledge will possess a competitive edge as well.



During my software development travels I have come across a few nuggets of usability wisdom which I’m inclined to share. What follows is a short list of some of these tips and tricks. These suggestions are mostly applicable to web-based applications, although there is no reason why they can’t be applied to standard websites.

1. Provide in-place animated feedback – using a JavaScript pop-up to tell a user they’ve forgotten to fill in a required field is not only old-school but just down-right annoying. You need to place a notice as close as possible to the point of error. In addition, it should not require a page reload, it should just appear in place using CSS and JavaScript.



In the example picture below you can see a fairly standard looking login box. The lower portion shows what happens when you click the ‘Go’ button without entering a username or password (i.e. a warning message appears). What you can’t see here is that the background for the red warning box was actually an animated GIF which started as a deep red color and faded to the pastel red you see. This animation makes it blindly obvious to the user where the problem is.

2. Put important messages in a yellow box – its common knowledge that users skim information on websites. The danger of this is that they may miss important information as they attempt to muddle their way through your content. The trick here is to encapsulate the information in a nice yellow box. Why a yellow box? Because it resembles a post-it note. People associate these with ‘reminders’ or important tit-bits of information.



3. Highlight recently added features – some of the more common approaches for letting users know when features have been added to their system include; sending them an email with a list of new features, putting a list of new features on the home page of their system so they see it when they log in, or putting it on a wiki which you expect them to come look at. In an ideal world these tactics would probably work. Failing that, it’s far more effective to just highlight the new feature in some way (whether that’s with a pastel colored background or a little icon that says ‘New’). An additional point is that these highlights should ‘fade’ over time, meaning that after one month, the highlight should disappear.



4. Hide features a user wont initially use – I’m sure there is no doubt in your mind that your software is fantastic, you can’t wait to unleash the fury of the 400 features your software has to offer. But spare a thought for the poor user who enters your application for the first time, they are suddenly inundated by buttons, drop-down menus, icons, pop-ups, fancy controls – it’s a foreign land, and the user is like a French exchange student who’s forgotten their phrase book back home. What can you do to help? By setting expanding panels to their collapsed state by default. When the user logs in for the first time, they wont be bombarded with widgets, instead they will be pleasantly surprised by the simplicity of your interface and will probably think to themselves “this doesn’t look so complicated, I can get this in no time”. Don’t worry, users will be curious and explore, they will click the expanding icons and discover how things work in their own time.



5. Let users reduce the complexity of their interface – this is similar to the Hide features a user wont initially use principle since its about reducing interface clutter. But this is something which is more likely to happen after your users has experience with your application. For example, a user may become so familiar with the system after a couple of months that they no longer need any pop-up help. These kind of options would commonly appear on a My Profile or Settings page. A word of caution here; allowing a user to set their interface to 'Beginner' or 'Advanced' mode may seem like a great idea, but what does this really mean? How does the user know what features will be hidden in 'Beginner' mode? Maybe some of the things you consider to be advanced features, the user would think of as being basic.



6. Give feedback messages which say what just happened – if you are giving users some kind of feedback after a button is pressed, that’s great (e.g. “Operation Successful” or “Task Completed” shown in a box at the top of the page). Taking this one step further involves presenting a little extra information about what just happened. For instance, rather then just saying “Upload Successful”, you may display a message like “The file holiday.jpg has been uploaded”. Why bother? Well, the web being what it is, people often wonder off or task switch in the middle of something. They could start some process in your application and switch to another browser tab or go read an email. Ten minutes later they come back to your application and wonder “what was I doing again?” Be sure to use feedback message sparingly, for reporting significant actions, especially for things which aren't instantaneous.



7. Use a red star inside textbox controls to indicate a required field – there’s nothing ground breaking about using a red star to signify a mandatory field, this is more of an optimization on an old concept. What you are doing is using CSS to set the background of a textbox control to a GIF of a big red star. This saves a little space and gives some additional control over UI layout. The other significant factor is it’s big, making it virtually impossible for a user to miss.



8. Provide a way to reset a control or interactive element – why provide a reset button? Because its a long way to the browser’s refresh icon or to the F5 key. Well, it’s not really that far, but you do whatever you can to optimize the speed with which a user interacts with your application. There is also some logic to placing a reset button near the controls it affects, it’s just a matter of convenience. To a certain extent this is a question of personal taste as you don't really need a reset button for most fill-in forms. This is one of the reasons why I use a small 16x16 icon for a reset button as I don't believe the space taken up by a full reset button is warranted.



9. Pre-fill textboxes with suggestions or instructions – if you have the space available, why not make use of it to give users informative suggestions or instructions. In the example below, you can see a portion of a standard contact form. A user can either choose an option from the drop-list or start typing in the adjacent textbox. The moment a user clicks in the ‘or’ textbox, the pre-filled text is blanked-out so they can type in their own custom subject. Below this is another textbox, this time we are letting the user know that this is an optional field. Using gray text rather then black is preferable since it diminishes the attention it attracts (its of minor importance in the overall scheme of things).



10. Use arrows to visually connect related controls – using a bent arrow to say “hey, these radio buttons affect how this textbox works” can be a real boost to the effectiveness of an interface. It provides a natural flow rather then the usual disjointed placement of controls. In the example shown below it would be pretty clear to a user that they have two options for refining the scope of their search (i.e. the arrow indicates an implicit connection between the controls).



Armed with these new usability tricks, you are ready to go forth and make the world a better place, or at least make your software more usable. Because usability isn’t a directly tangible thing that can be listed on a project schedule, it’s often ditched in favor of more features or additional quality testing. This way of thinking isn’t going to last much longer as more users are spoilt by the fantastic interfaces they receive from companies like Google and Apple, people are coming to expect usability as a given, not a treat.

Special thanks to Dmitry Fadeyev of Usability Post for his excellent suggestions which helped improve this article.

Wireframes and Mockups - Part I

Lo-Fi techniques for creating effective UI wireframes.

Part 1 focuses on lo-fi approaches such as pen and paper-based techniques. Part 2 is concerned with more refined tools for producing polished UI mockups.

UI mockups, or wireframes, are a major part of any respectable functional specification. A functional specification is a description of how the software will work from the user’s point of view. This article doesn’t cover the reasons why you need a functional specification, for this I would suggest Joel Spolsky’s article Painless Functional Specifications. The focus of this piece is to describe and analyse a few approaches for creating UI mockups.

I’m sure there are many other approaches for creating wireframes, but I can only describe and comment on the ones I have used, making some general statements on what is good (or bad) about them.

Lo-Fi Prototyping – this is just the fancy name for the old butcher’s paper approach. Hands down, its the best technique when a new shrink-wrapped software package is being designed. It really lends itself to collaborative effort, it gets the creative juices flowing, and the speed at which you can produce rough screens is unbeatable.



I once spent four days with a group of developers in a small apartment designing a telecommunications application using this technique. The result was just short of astounding, it allowed us to blast out and iterate ideas very quickly. As the UI designer for the team, I went home at the end of the week with a mass of paper which I turned into over 30 HTML mockups.

This approach is unsuitable for designing simple business websites or software which has been done before (e.g. non-novel systems like a shopping cart). It’s also not so great when a client is directly involved in the project. There are a few reasons for this; it requires a big investment of time on the client’s behalf (they may have a business to run during the day), and secondly; the client-to-supplier relationship often creates a dynamic where they tell you what they want, and you go off and make it. Normally, the client wont hang around whilst you design their software.

Microsoft Excel – yes, as strange as it may sound, MS Excel can be quite handy for producing wireframes, especially for software which is expected to have long vertically scrolling screens. I would never have thought to use it myself, but a company I worked for introduced me to it as their preferred spec’ing tool.



At first I was skeptical, but I quickly warmed to the approach when I saw how fast screens were to make once I got the hang of it. It’s excellent for inserting instructions to programmers (either in comments or as side-bar text). It does however produce exceedingly ugly wireframes; this is a good thing for application design since it keeps everyone’s focus on usability and business logic.

The other great thing about Excel is everyone is familiar with it, including clients. The closest thing I could think of as a criticism of Excel as a wireframe tool is that it produces decidedly uninspiring visuals. I currently don’t use Excel as a wireframe tool, but I would have no problem picking it up again if I felt it was right for a project.

Microsoft Word - another desktop application you wouldn't normally think of as a wireframe tool, Word can be pretty good in certain situations. Generally, the only time I would use Word to represent UI controls is if I am making a ‘mini-spec’ for a web-based application.



A mini-spec is created in one of two situations; as an adjunct to an already ratified functional specification, or as a mechanism for grouping together a bunch of features for a version upgrade. UI controls are represented in a very rudimentary fashion, for instance; (*) would be a radio button, and [x] would be a checkbox, etc.

This works because the interface for the system has already been established (i.e. the system has been coded or a Photoshop mock-up exists). The advantage of this approach is speed; you describe the underlying functionality of the code and only mock-up the controls relevant to the feature rather then drawing the entire screen.

Continue on to part 2 of this article to find out how Visio and Photoshop can be used to produce highly refined mockups.

Wireframes and Mockups - Part II

Techniques for creating polished UI mockups.

Part 2 focuses on tools for producing polished UI mockups. Part 1 is more concerned with lo-fi approaches such as pen and paper-based techniques.

Over the past few years I have been exposed to a number of techniques for preparing mockups. Each approach has its strengths and weaknesses, but generally the best method to use depends on the project at hand. I don’t have a single preferred approach, but choosing the most appropriate style to use at the time can be a tricky undertaking.

HTML mockups – with the advent of tools like Microsoft FrontPage and its successor Web Expression, anyone can make cool looking mockups, to the point where it seemed as though all that was left to do was hand over the HTML to the programmers, and they would take care of the rest.



I’ve used FrontPage to make HTML mockups quite a bit in the past. Some analysts say its a very strong option for designs because it allows you to produce navigable HTML. From my experience, I don’t think its a good choice to use as a first draft system, it can be time consuming and lures you to distraction by unnecessary detail early on (i.e. making the design ‘look pretty’).

The biggest problem with HTML mockups is you have nowhere to put annotations (i.e. generally tech notes directed at programmers describing ‘under the hood’ functionality). As far as navigable mockups go, I’ve never found it to be a big issue with flat mockup structures. Generally people know where pages are going to go to, and in rare cases when a page is going to the wrong place, its nearly always a rudimentary task to direct it elsewhere.

There is one instance when a HTML mockup is appropriate straight away. This is when a complex new screen is being added to an already established interface. The reasons for this are beyond the scope of this article, but suffice it to say that experience has shown that its quicker then first creating a lo-fi version of the UI. One of the other great things about HTML mockups is that they’re easy to distribute to people.

Microsoft Visio – this is the tool I use at the moment for wireframes. It strikes a good balance between flexibility, professionalism, and speed. Visio is great for putting in tech notes without interfering with the wireframe itself, I generally put these in a sidebar to the right.



Visio interfaces come out looking nice and plain, which is what you want. It also has drop-in vector art for all the most common form controls you need (e.g. textboxes, radio buttons, etc).

I find that Visio is well suited for use with clients and their custom web applications. The only fault I can find with Visio is its hard to distribute files, few people have Visio installed on their computers (especially clients), but this is easy to get around, I just print wireframes to PDF.

Photoshop – mainly used by graphic designers to create compelling visual layouts. The beauty of Photoshop is realism. This can be quite exciting since it creates a real buzz on a project, as though things are starting to shift from concept to reality.

Photoshop is best used for creating a single highly polished UI screen. For example, just the home page of a business website, or just the landing page of a web-based application. I have seen graphic designers produce every expected screen of a business website in Photoshop, this is totally unnecessary. The client will get what their website is going to look like from just the home page (i.e. it establishes what the overall look and feel of the website will be).



The obvious short-coming of employing Photoshop is the skill required to use the program, it often takes years just to become proficient with the tool. Iterations can often be slower then other techniques, especially when a complex design with many layers is involved. On the plus side, distribution is a breeze since Photoshop can save image files which anyone can open (e.g. JPEG or PNG).

One of the perils of making wireframes which are seen by a client is the tendency to get distracted by cosmetic factors (e.g. client: “why is everything grey?”, “can we have that button in green?”, “that’s not our logo!”).

Generally what I do before designing anything is tell the client “I’m going to make some very rough mockups of how the screens will look. It wont be pretty, but at the moment we are trying to lock-down where buttons go, the general layout, etc”.

This is where methods like lo-fi prototyping or MS Excel can be helpful, because the screens can’t help but look hideous. The danger with mockups in HTML or Photoshop is that effort can be spent early on ‘making it pretty’. The problem with making things ‘look pretty’ at early stages is time gets wasted when iterative adjustments occur (which they will).

Iterations are the name of the game when designing a system, especially early on. If this is the case then you want to choose the approach which is going to allow you to churn out revisions at super-high speeds.