4 reasons why you need to solve UX issues in the browser

While working on SnowflakeStories.com we had many difficult challenges to solve.

Amongst them stood questions such as

    • Would our choices make sense in a mobile format?
    • How well would it work on desktop?
    • The true test: could the founder's parents figure out how to use them? (Grandparents are in the target market)

I recently discussed my technique of refining the UX of SnowflakeStories.com. I explained how I create simplistic sketches and jump right into code as soon as possible. Here I want to expand upon some of the benefits of taking this path and how it relates to Design Systems Engineering.

This approach has the following strengths

  1. Start using the app in a simple way by clicking to navigate
  2. View across a variety of use cases and devices
  3. See precision rendering, not some strange simulation or alteration of sorts
  4. Give people a reasonable experience of your product, site or app

To expand upon #4 I want to talk about suspending disbelief.

This film theory is how viewers in certain circumstances will interpret the film as being real . If for example you setup your world as having reverse gravity at the beginning, your viewer understands this as truth. If you change this later, this might shock the experience of enjoying the film out of them.

When you create a bunch of in progress design files, you can sometimes simulate an apps behavior. However, this is just a simulation. This is a big ask. You are asking them to them pretend it is an actual working app.

Now as UX and web tech professionals, we can examine sketches, wireframes and mocks and understand what the final project will look like.

Key Takeaway

Others need more persuasion to suspend their disbelief.

Browser viewable code does this in a powerful way and also is easy to make sense of.​

Sure this may not have the strong visual brand or the exact colors of your product, yet. But "normal people" will figure out how it works. They will know how to click, swipe and otherwise interact with the app on their device of choice.

So hands down, a simple scaffolded app wins over wireframes and mocks because it simply works the way people expect.

Going forward the advantage is that you may build much of the scaffolding. This is a byproduct of the process. Even as you continue to iterate, you will end up with most the scaffolding built out.

Scaffolding is one of the most powerful ways you can use Design Systems Engineering. This streamlines your app development process. This is the precursor to your front-end code and coded styleguide.

You are killing (the math is not exact here) about 2.3 birds with 1 stone.

So this all sounds great in theory. But does it work in practice?

In my experience yes as long as you are working from broad strokes to somewhat smaller strokes as you go.

Things go wrong is when you try to build out very complex interfaces with a high level of detail.

There is certainly a time and a place for this approach, but I would urge you to think broad in terms of your app first. You need to get the big questions answered first before you can deal with the smaller details with any sort of certainty.

Right from the initial sketching phases Design Systems Engineering can help streamline your process.

As you continue to iterate, you can build out a set of consistent code and documentation that will allow teams of any size to build faster with more consistency.