Design

The Techrangers serve a large cross-section of UCF. We serve cutting-edge faculty excited to try new things, but also stretched-thin faculty who are simply looking for solutions. We also serve all kinds of students - Business majors, History majors, Computer Science majors, English majors, local students, international students and just students who are juggling multiple classes, jobs, social lives, and are trying to learn at the same time!

Building things that work for such a varied audience can be challenging. Faculty may grow frustrated at an application that feels fun but is confusing to use. Students may yawn at something that works well but feels outdated. Worse of all, applications that aren’t built with accessibility best practices can exclude others. For example, users who are visually-impaired may not even be able to use that application if it doesn’t work with a screen-reader.

Been there, done that - we’ve made many mistakes over the years. That’s why this book exists - to share the ideas, strategies and resources we’ve collected to help you (and us) build well-designed products.

You may consider yourself a pixel-slinging front-end wizard, or a code-wrangling back-end guru who fears anything CSS (…truthfully, we all fear CSS). In any case, this guide will have something to provide for everyone.

Last, remember that the team as a whole is here to help you when you need help and to grow your skills.

More than good-looking pixels

Great design is more than making sure the websites and applications you build look good. They also needs to function well for all users, be clear, consistent and direct, confident, and should (at its best) delight rather than frustrate. Since we’re an educational institution, our additional mission is that we want our designs to promote (directly, or indirectly) learning. In the end, our goal is to build things that help students learn, help faculty teach and help staff make that happen.

Mock-ups first!

Building an interface? Before you start writing HTML or playing with CSS rules, we recommend that you mock it up first! It’s easier to play with ideas and iterate on an interface when you only have to move pixels or boxes around rather than re-writing code.

• One great and free software tool for creating design mockups is Figma!

LS&T Figma Team

We have a team on Figma you can join! We have some designs there for current projects that you can check out for inspiration, or so you get a more technical look at how Figma works. If you want to be invited into the team, create a Figma account using the link above and then contact either Danny or Jacob to be invited!

Getting feedback

For feedback we have the aptly named #design-feedback channel in slack. Everyone on the team is welcome to join and comment. Drop some screenshots or a link to a mockup, and ask the group for feedback and if they have any recommendations.

You might get some thumbs up of approval, and some confidence you’re on the right track. You could get a few suggestions. Or, if the Moon phase is just right, you might find yourself flooded with comments. Don’t worry - this is a good thing, even if it feels overwhelming in the moment! If you feel yourself getting upset or angry (we’re human - it happens) take a moment to breathe, center yourself, and remember we’re all in this to make good software. Everyone is trying to help, and comments are about the design, not about you personally. You can explain yourself if you feel like it would clarify things, but there’s no need to get defensive or feel like you have to defend your choices.

Your first design WILL have problems

And that’s okay! There will be things you didn’t think about. There will be things that you thought were clever that others may not get. Someone might even object to the orange and blue color-scheme (made infamous by some other college not named here).

The important thing is asking for feedback early and often. It can sting a bit, as your design gets critiqued and analyzed by your peers. But remember that we’re all trying to make great software, and it’s important that all of us help improve the final product. It’s not you we’re critiquing, it’s the design! And we don’t expect you to nail it on the first, second or even 10th time.

Parsing feedback

It’s also important to remember that feedback can be varied, and we all have our off days. You’ll have to think critically about the feedback you get. If a team member simply comments “It’s confusing” without much more, you may need to prod to get them to explain what’s confusing about it. If a team member makes a suggestion for an improvement that simply isn’t doable or wouldn’t make sense if they knew the context of what you’re asking for feedback for, thank them and take the parts of their feedback that’s usable and put aside the rest.

Pitfalls

It’s also tempting when having a design critiqued to defend it. Let’s say you’re showing off a user login page. It’s easy to slip into a conversation like this:

Emily: There should be a forgot password link probably
Michael: Oh yeah, I have that - it's just not on that screenshot
Emily: gotcha. Also the username and password boxes aren't centered
Michael: I fixed that already
Emily: kk - and i think it should use the new color scheme we're using for that site
Michael: I know - we're going to do that for the next version

To avoid feedback like this, you might want to provide context with whatever it is your sharing. But try to avoid defending the design too much. Emily in this example could become discouraged to providing any more feedback for fear that Michael will say that it’s a known issue! Instead, Michael would have been better off simply thanking Emily for her feedback, showing her the fixed content, or bringing her in for feedback more often.

When to ask for feedback

Early, and often! This can help you avoid a scenario where you may be showing off a polished near-final product and realizing through feedback that a key idea to your design doesn’t work. Switching gears is much more difficult, painful, or simply not possible if you’re too far along.

Giving feedback

Have some ideas for how something can be improved? Chip in! The more voices we get, the better off the final product will be. Still, there are a few tips to keep in mind when giving feedback

1. The golden rule: Don’t be a jerk! The goal here is not to make everyone aware of your superior taste and skills as a designer. The goal is to help the design and spread knowledge to the team.
2. It’s okay if you don’t have a solution to a problem you bring up! Stating something that’s confusing or that you have issue with, even without an answer, is helpful to know. Maybe someone else has some ideas to solve it.
3. Throwing out ideas, even if you feel they’re not winners, is good too. Why? Because that’s brainstorming, and someone else may be able to riff on your idea and improve upon it.
4. Feel free to ask questions. Who’s the audience? Will the user of this application know the terminology? What’s the gear icon do? You’ll either get more information to help you critique the design effectively, or you’ll make it known to the designer that something’s not clear since you had to ask for clarification - both good things!

Striving for Usability, Accessibility and Universal Design

You will often find that the design of a product such as a website, has to be extremely approachable and intuititve. This is because a lot of different eyes will be seeing it and working with it, sometimes on a daily basis (depends on the project). Because of this, you want to approach solutions to your implementations being cautious of the components you use and how!

Every now and then, take a second to look at your work from the client’s perspective and make sure the components you use show their purpose effectively. In the tech world, a lot of our clients are people who don’t know programming, so it’s important to make the product accessible to them, not just us. Focus on building components that will serve their purpose for as long as the client might need them; strive for longevity in your code, it will save you the headache of reworking your code in the near future!

Accessibility is another incredibly important foundation for every piece of work you should be delivering. When building your code, make sure you consider it is possible there may be users on the receiving end of the project that may need more help processing the work you put on the screen. You could be delivering a project to somebody who oversees one or more people who are hard of hearing or have difficulty reading text in smaller fonts. For this reason, focus your approach towards using the component tools available to you, such as alt text on an image object or captioning on a video you imported! They will appreciate you taking these scenarios into account and you will be a more considerate developer as a result!

As stated earlier, it’s very important to make your product accessible and durable, and one easy way to follow this mentality easier is to use popular CSS frameworks such as Bootstrap or Material UI that are favored by many websites! These take out a lot of the hassle of working with CSS, and allow you to focus more on the functionality of your product, rather than fully developing the look of it!

Asking for design help

As stated before, the #design-feedback channel on Slack can be a great spot to get feedback on your design ideas! If what you’re looking for is more on the technical side, a better channel to get help is #rubberduck. Don’t ask. Just kidding, you may!

But anyways, this is the hub for your concerns with your design process and any troubles you may find while you’re programming.

Compromises and the reality of the deadline

The truth is, at the end of the day we have to ship software. As much as we’d like to spend as much time as we need to get each drop shadow juuuust perfect, compromises have to be made in order to ship. That requires prioritization, shortcuts (when beneficial), and getting help.

An often good practice is to focus on functionality first, design second. Your implementation may look extremely pretty, but if it can’t function, no one’s going to want any part of it! Of course, if you know what would look best as you develop your work and it doesn’t slow you down greatly, you’re welcome to apply the CSS needed as you go!

Prioritization

You may need to postpone things you want to do to a future release. As stated before, there often comes a time where you have to forsake some design aspects for the sake of functionality. If not all of the goals are met by the deadline, you might get some disgruntled reactions about your work. To avoid this completely or at least litigate it, it’s important to take their biggest concerns to heart.

• What did the client need the most?

• How important is it to them that the UI looks very neat on delivery? Do they care more for results rather than pretty solutions?

These are some questions you can ask yourself that may help you tackle the task of finishing and delivering a result that you can be proud of!

Useful tools for UI design and brainstorming

• Storybook

• Figma

• Bootstrap

• Material UI

Things to avoid

• In the tech world, it is very common to overextend and burn the candle at both ends, a phrase one may use to describe somebody pushing themselves to their breaking point. It is very important you don’t do this. The work you do is important, but your mental health is more so. Always try to keep a grasp on what you can handle and remind yourself that it’s okay to take a moment to breathe every so often!

• Don’t close yourself off to new ideas and comments about your work! We’re here to help each other grow stronger, taking and giving critical feedback so we can all become better programmers in turn!

• Tech industry being as competitive as it is, it’s very easy to fall into a competitive mindset and find yourself always trying to be better than the person working alongside you, whether on the job or not! On the job, this can be a very good motivator to improve on your skills, but it may also put you in a situation laid out in the first two points, if taken too seriously! Make sure your competitive drive with your peers is welcome and encouraged, and that you’re not putting anybody down for work that you might believe is lesser to yours.

That covers everything you should keep in mind, from designing new components or full-on websites! It is a lot to read so please feel free to come back if you want a refresher sometime, that’s what the handbook is for!

Now go out there and code up some awesome stuff! :)