I’m super excited about CSS grid, because finally there’s a way to layout pages and achieve more interesting and dynamic results, without a ton of code! So since I fell in love with Atom IDE recently (I know, I’m late to the party, but really I like it 😺), then it’s no surprise that I will be using it for this example on CSS grid layout.
The heart of creating a LSG is the ability to put your documentation right where it belongs: in the source code. Chances are that you are already documenting your code, which is a great opportunity to take it to the next level by using a style guide generator that can turn those comments into an organized site, letting others (and yourself from the future) know why and what has been done in the code.
While the bulk of your LSG documentation will come from special comments that you add to the source code, you can also create standalone pages where you can host other types of content that are not specific to the code (think of design principles, accessibility guidelines, or pull request guidelines). This gives you the advantage of centralizing your documentation in one place: your application living style guide.
Using a living style guide (LSG) to drive development is a practice that is gaining a lot of popularity because its many advantages, including code efficiency and UI consistency. But, how can you create one? What should you include? And where do you even start? In this 3 part tutorial I will delve into the nitty-gritty details of creating a living style using DocumentCSS.
User testing is a great way to validate assumptions and gain new insights about how people interact with our websites and apps. When it comes to eCommerce (and in particular mobile commerce or “mCommerce”) it’s critical to understand how people find and purchase products online. This was evident on one project where we were tasked with testing the mobile website design for retail membership giant, Sam’s. As it turns out, there are many common navigation patterns that aren’t nearly as effective as people might think.
Think of the app on your phone that you love using: the one that just makes sense when you use it, the one that feels like it was built with you in mind. This is good UX or User Experience. Good UX makes an application sticky; it invites new users and retains active users. UX is the process of designing an application (or product) that is intuitive for people to use by considering how they will use it. Intuitive interactions are important for every project simply because people like things that are ‘easy to use’. However, creating a product that is easy to use takes lot of time, expertise, and iterations.
There is nothing more rewarding than watching people use your app and seeing how they interact with it. User testing is a lot like making dinner for someone; you choose a recipe, ingredients, and invest time making a meal you hope your guests will like. Then you sit down with them and talk about what is good about the meal, what could be improved, and if you’d make it again. At Bitovi, we put a lot of value on testing our designs (and our assumptions!) to be sure we’re building the right thing for our clients and our clients' customers.
The goal of every UX team should be to solve business problems with thoughtful design solutions. In fact, I’d say it’s not difficult to find a designer or agency who can create great-looking designs. Beautiful and useful design is a given in our industry. At Bitovi, we do those things too - but I want to know what makes our design team different. I want to help people understand why are we uniquely qualified to work with our clients.
We’ve all been there, we start designs for a new project and have the best intentions to test our designs with users. However when priorities are defined, “shipping it” gets in the way and our good intentions are blown away. The good news for Agile teams is that there is a workflow for making usability testing part of your design process. In this post, I will share 10 best practices to help you get there: