Categories
Design Development Reviews Upgrade

We’re in transition.

Following on from my previous post, we’ve updated and maybe tidied a few duplicates.

There’s also been many discoveries along the way too. Stuff that doesn’t work nor spotted in system, which makes one think are these features ever been used?

Prioritising the ‘must’ from ‘nice to have’ fixed bug features is good, but could be better managed. Questioning whether they are in use or not, and to fix any major issues found along the way.

Of course business doesn’t just stop when there’s a major change, so there’s new features made in the pipeline ready for deploy.

The issue is having merge conflicts, between branches especially if there’s been many tweaks across branches.

Sometimes doing less is as valuable as doing more. So the point to take away here is accept temporary changes inbetween branches.

Yes, it’s not great for the user experience as things may look different between merges, but then again question whether there’s greater value in doing these changes in a time of merging features?

Reducing number of conflicts reduces number of hours spent revisiting repositories to review changes and a larger gain to being productive developing and improving features.

A valid point, do users prefer working software oppose to something just looking nice?

Ideally, best of both worlds would be great, but the reality is, there’s a limit to most things in development and a far greater possibility to revise designs/styles once features are merged and streamlined into few branches.

That’s where we can now develop new features in priority starting with aesthetics.

On a side note, how many developers have worked with Bootstrap 4 and noticed something interesting?

There’s a class for nearly every style, no need to customise the CSS, but for colours.

Why so many classes?

It also reduces the amount of conflicts found across the system when styling with classes especially if you’re not used to CSS (from an entry level) or the system if it was made before your time.

It’s also safe when upgrading a system, if a team were to use existing classes instead of custom classes or CSS.

Categories
Reviews

Quick Changes

There are times when things need completed urgently.

But there are methods to go about it.

First think about the 5 W’s.

Who, what, when, why, where.

Apply this logic to one of your tasks.

The ‘who’ will factor the ‘how’ situation, so don’t worry there.

But wait just there!

That’s great for adding features.

Anyone thought about removing features?

Check first if there are other features around the feature you’re about to remove.

If it’s the only feature there, question yourself again the following…

Does it look odd?

Before removing a feature that’s self isolated, try creating a replacement feature.

Without these scenarios, things will turn out half baked.

Categories
Design Development Reviews

Sometime it’s not clear

It’s not always clear what to expect when building software especially when you’re reliant on user stories that don’t describe the full story.

But then again, sometimes user stories can’t be clear without some visual concepts what the users needs.

From experience with visual concepts, many users thought this was it, concrete.

Maybe that’s because it’s down to how polished a design concept is.

Depending what you’re target audience is, it should be very basic to explain itself to the user what each element of a concept does.

Factor in the user’s knowledge of what they may currently know to build the amount of detail needed in the design concept.

We all have to remember that visuals are just concepts, therefore there may be some changes in the pipeline that weren’t considered back then and that they may need looking into present.

Trying a different approach without the visuals is another challenge.

So when you’re building from scratch it only makes sense somewhere along the line where smaller components fit together but still don’t describe what they do.

Adding titles, labels, icons makes sense.

Then you start to see a pattern of inconsistency delivered in Agile methodology, that’s where you’re suppose to constantly deliver.

Sometime it’s better to extend and add a sprint to rectify these issues before it gets complicated to work with.

Yes it adds some time to productivity, but would you rather have this or the latter?

Categories
Design Development Marketing

The point.

If you invest in a little bit more time, you get a whole lot more in return.

Take this as my experience.

If you take a look closer you will see patterns.

Keeping things generic as possible offers flexibility and new ideas.

Although time does come at a cost, think of it as a return on investment.

When you are finally done, release and track your feedback.

The jigsaw to the feedback will be crucial.

With the feedback, improve those negatives to positive.

You then reiterate and evaluate, eventually receiving the cycle of success.

Statistics will show, performance will grow.

Be patient, calm and collective.

One at a time is the focal point.

There is a journey where we are all involved.

Making the end users experience greater together then the previous or current.

Love to hear your thoughts and comments. Please leave them below, thank you.