From Wikipedia, “The user interface, in the industrial design field of human–machine interaction, is the space where interaction between humans and machines occurs. The goal of this interaction is effective operation and control of the machine on the user’s end, and feedback from the machine, which aids the operator in making operational decisions.”
User interface (UI) design is a crucial aspect of software development. Without proper UI design, software - no matter how great the intention, technical wizardry, or investment behind the application - will be difficult to use and not widely nor joyfully adopted. In order to develop software that is truly intuitive and clearly answers a need, the team behind it must have a deep understanding of not only the underlying technical platform and data, but also of the people who will be using it, and WHY they’ll be using it.
At the Gartrell Group, we strive to make every application that we develop intuitive, easy-to-learn and use, and well-fitted to the understood needs of i
ntended end users. This is consistently one of the single biggest topics of conversation and areas of focus in our company; it’s an area where we constantly self-assess, try refinements in our approach, and review industry trends and pearls from the blogosphere for ideas that might be integrated into our design practices.
Making a sweet UI; it’s not an easy task. But it’s really satisfying when carried out successfully.
Designing an intuitive and useful UI is a group effort that involves extensive communication between the client and our design team. For good design to happen, customer advocacy needs to extend from the whiteboard back to the coding station – business needs and the purpose of a software tool must guide all and be a reference throughout the full lifecycle of design and development.
OK, but how do you manage that? People profess lots of ways and even standard methods have lots of different interpretations, flavors, and personalities. Here’s a list of principles and practices that our team has developed to guide our work through an application development project. It’s not in order of priority. We treat them all with equal importance.
An effective user interface should be “pleasing”.
What we mean by this is that the UI should please because it looks good (it has good form, aesthetics), it simplifies complex tasks and operations (it functions well), and because it makes work faster and easier (it is tightly bound to the business mission).
View the UI through the user’s eyes.
We like to get insights early. This often means that our team will spend time with the people who will be using the application we are building so that we can develop a deep understanding of the users and their needs. We find out what their objectives are and what questions they seek answers to when they access an application. Knowing what their workflows are, what they’re pain points are, and what is working well for them is very valuable to us and informs our UI design work.
Depend on Clients to Define the Problem, Collaborate in Designing the Solution.
This can be a subtle thing, but it’s important. We have learned to focus our clients on describing the problems they want to solve rather than defining the actual solution. The burden (aka creative pleasure) of solution development is one that we should bear or at least share with our clients. After all, we’re bringing expertise in information architecture and UI design and this is an important part of our service offering and value proposition. By applying this to client challenges, we have developed a pretty good track record of arriving at pleasing, effective solutions – which may often be quite different than what our customers had initially envisioned. That said, users will also often have clever and thoughtful ideas about how to solve their challenges (ideas which may or may not be bounded by the standards of UI design). Often the most elegant solutions will stem from a combination of our expertise blending with the user’s articulation of their needs and their creative input.
Good design comes in iterations.
We generally start with a low-fidelity sketching or wireframing and move progressively into testable prototypes. Our development practices also proceed through cycles of presenting tools-in-progress and providing customers with regular opportunities for review, testing, and for design refinements based on findings from those activities. There’s a lot of discussion and different schools of thought on the viability of wireframing vs. prototyping, static illustrations vs. responsive design, and so on. We recognize that different projects may be better served by slightly different methods and approaches, and so we tend to be more integrative than dogmatic in our design methods. Whichever approach we feel is most appropriate for a project (wireframes-to-prototype, straight-to-prototype, etc.), there will nearly always be cycles of design-review-revise-expand-review. Our team will work closely with the client team on every step of the process; presenting and discussing the iterations as the design process advances. Design work, for us, is concentrated at the front end of a project, but there are elements of design refinement that parallel and weave into the whole development process.
Model everything.
The UI is the face of a larger, integrated system involving data, backend technologies, and users. We find that modeling and illustrating the 
relation
ships and connections between the different components of a system is very beneficial to UI design – it’s a good technical reality check, another way of making sure key needs are being addressed and considered at all levels, and a means of assuring your system is staying true to mission. Our solution architecture work tends to involve three core model types:
- A system model will give a clear understanding of the logic and rules of the system. Our solution architects will work closely with the client’s technical team to ensure that the data relationships are correct.
- An interface model will show how the system is presented to the user through its UI. This will show how the user works with the underlying data and technology via the UI.
- A user model will show how users will interact with the system. Different users will have different interactions and needs. We try our best to model each user’s workflow so that we may design optimal ways for them to accomplish their objectives through interactions with the software tool.
Delivery team communication is critical.
It’s critical that communication about what can be drawn vs. what can be rendered in technology with ease and positive effect be an ongoing dialog. The design work cannot be done in a vacuum, it needs to be shaped and constrained in certain ways by technical standards, and technology needs to be bent to and shaped into design. There is always a tension here – we have organized our practices with the goal of keeping it a healthy tension. One way to do this is to have a rational sequence of design and build subtasks. Ultimately important, though, is to have regular check-ins, internal reviews, and discussions to confir
m that the pieces of a software solution will “click” together happily and all the way through a succession of design and build cycles.
Test, test, test.
Testing can reveal possible UI needs that were not understood while the application was in development. It happens: we may think a particular UI approach will work well when it’s in sketch form or presented as a lightweight prototype, but then realize through testing that it’s not going to be a fully satisfying solution. This is actually a good thing – or at least better when learned up front than after rollout. Our goal is to have clients testing early and often — as soon as possible — so that we can see what works and what doesn’t. Even with focused effort on design, the reality of using a tool can reveal opportunities for adjustment and refinement that will make it even better. Testing can also help reveal discrepancies between web browsers (we’re looking at you Internet Explorer) and platforms. With the rise of mobile computing, we need to have a good understanding of the means by which our end users will be accessing the application and testing across all of them.
Be willing to learn new tricks
This list is ever evolving and changing – just like the methods and means behind software design and development. Software design is a dynamic space. There are always cool new tools and ideas emerging that continue to improve our capabilities to more closely and effectively match user needs to software functionality. As may be evident, we are not settled and staid in our own methods and we enjoy participating in the discussion and movement of the ever evolving ‘best practices’ of design work.